[U-Boot] [BUG ] efiloader: incorrect creation of *.efi file

Heinrich Schuchardt xypron.glpk at gmx.de
Sat Jan 19 18:27:55 UTC 2019


On 1/19/19 6:54 PM, Alexander Graf wrote:
> 
> 
>> Am 19.01.2019 um 17:40 schrieb Heinrich Schuchardt <xypron.glpk at 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


More information about the U-Boot mailing list