On 1/19/19 6:54 PM, Alexander Graf wrote:
Am 19.01.2019 um 17:40 schrieb Heinrich Schuchardt xypron.glpk@gmx.de:
On 1/19/19 12:55 PM, Heinrich Schuchardt wrote:
On 1/19/19 11:21 AM, Heinrich Schuchardt wrote: Hello Alex,
bootefi hello fails since 5be444d14b380b210b246aa73dd5a111e4b1f80d efi_loader: consistent build flags for EFI applications
The problem is caused by incorrect entry point information in the EFI binary:
Actual positions in EFI file: 0x178 hw_memcmp.constprop.0 0x1a8 efi_main
Header information in EFI file (using https://github.com/xypron/efi_analyzer):
BaseOfCode=0x148 AddressOfEntryPoint=0x148
So AddressOfEntryPoint is not pointing to efi_main().
In arch/arm/lib/crt0_aarch64_efi.S we define AddressOfEntryPoint to point to _start. _start() calls _relocate().
We already do a relocation in efi_load_pe(). I cannot understand why the code should be relocated twice.
Best regards
Heinrich
Though I still do not understand why we call relocation twice the real bug seems to stem form a call to a non-existent memcpy() function.
See address 0x74 of the disassembly.
Ah, yes. You must not use -Os for the efi binary, otherwise it pulls it back in. I guess I should've put a comment there...
Alex
As GCC is explicitly requiring that a freestanding binary has memcpy this is gone to break some day again. I have created a patch series that adds the missing functions to all *.efi binaries.
It is currently running on Travis CI.
Could you, please, comment on the question of duplicate relocation.
Best regards
Heinrich