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.
https://gcc.gnu.org/onlinedocs/gcc/Standards.html teaches: "GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp."
struct efi_simple_text_output_protocol *con_out = systable->con_out; 60: f940203b ldr x27, [x1, #64] u16 rev[] = L"0.0.0"; 64: aa1303e0 mov x0, x19 struct efi_boot_services *boottime = systable->boottime; 68: f940303a ldr x26, [x1, #96] u16 rev[] = L"0.0.0"; 6c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 70: 91000021 add x1, x1, #0x0 74: 94000000 bl 0 <memcpy>
/* UEFI requires CR LF */ con_out->output_string(con_out, L"Hello, world!\r\n"); 78: f9400762 ldr x2, [x27, #8] 7c: 90000001 adrp x1, 0 <hw_memcmp.constprop.0> 80: aa1b03e0 mov x0, x27 84: 91000021 add x1, x1, #0x0 88: d63f0040 blr x2
Regards
Heinrich