On 10/12/2018 11:02 PM, Heinrich Schuchardt wrote:
On 10/12/2018 03:45 AM, Bin Meng wrote:
Hi Heinrich,
On Fri, Oct 12, 2018 at 6:10 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 10/11/2018 03:57 AM, Bin Meng wrote:
Hi Heinrich,
On Thu, Oct 11, 2018 at 9:48 AM Bin Meng bmeng.cn@gmail.com wrote:
Add qemu-x86_64 to the list of targets we use for test.py runs.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
testp.py testing is currently failing at 'bootefi selftest'.
Can you try this series for the 'bootefi selftest' testing?
I am clueless why the EFI subsystems is failing completely on qemu-x86_64_defconfig.
Any printf() or puts() statement I put into lib/efi_loader/efi_boottime.c leads to no output at all.
I connected gdb with
gdb u-boot -ex 'target remote localhost:1234' add-symbol-file u-boot <relocaddr>
But the debugger did not stop at breakpoints.
I encountered exactly the same issue that breakpoint is not hit when debugging this endless loop issue. And I finally figured it out:
The symbol table should not be loaded to <relocaddr>, instead it needs to be loaded to <relocaddr + .text - .text.start>.
The .text.start was introduced in commit 7e21fbca26d18327cf7cabaad08df276a06a07d8 "efi_loader: Rename sections to allow for implicit data", and its commit message mentioned: [agraf: Fix x86_64 breakage], although I was not sure what x86_64 breakage was fixed.
Please have a try.
Regards, Bin
Hello Bin,
thanks for your hint. Now I was able to debug the problem.
The code is not correctly relocated.
Function do_elf_reloc_fixups64() only analyzes re_src->r_offset but not the relocation type.
I put a print statement into the relocation loop and found the relocation type of the first relocation to be reported as having an illegal value of 0x10ff70. All other relocation types were reported as 0x8 as expected.
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c index ed10755d9c..095374830f 100644 --- a/arch/x86/lib/relocate.c +++ b/arch/x86/lib/relocate.c @@ -55,6 +55,7 @@ static void do_elf_reloc_fixups64(unsigned int text_base, uintptr_t size, do { . /* Get the location from the relocation entry */ . offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
- printf("Reloc type %llx\n", ELF64_R_TYPE(re_src->r_info));
. . /* Check that the location of the relocation is in .text */ . if (offset_ptr_rom >= (Elf64_Addr *)(uintptr_t)text_base &&
Reloc type 10ff70 Reloc type 8 Reloc type 8 Reloc type 8 ..
The relocation types in efi_runtime_relocate() are complete garbage:
efi_runtime_relocate: 8 efi_runtime_relocate: 30 efi_runtime_relocate: b0 efi_runtime_relocate: 8 efi_runtime_relocate: 50 efi_runtime_relocate: 20 efi_runtime_relocate: 8 efi_runtime_relocate: 60 efi_runtime_relocate: 20 efi_runtime_relocate: 8 efi_runtime_relocate: a0 efi_runtime_relocate: b5 efi_runtime_relocate: 8 efi_runtime_relocate: b0 efi_runtime_relocate: aa efi_runtime_relocate: 8 efi_runtime_relocate: c0 efi_runtime_relocate: c0 efi_runtime_relocate: 8 efi_runtime_relocate: d0 efi_runtime_relocate: 68 efi_runtime_relocate: 8 efi_runtime_relocate: e0 efi_runtime_relocate: b5 efi_runtime_relocate: 8 efi_runtime_relocate: f0 efi_runtime_relocate: cb efi_runtime_relocate: 8 efi_runtime_relocate: 0 efi_runtime_relocate: e1
I will send a patch for efi_runtime_relocate().
Bin, can you please, have a look at the first problem.
Best regards
Heinrich
Using a memory watchpoint pinpoints the culprit overwriting the relocation table with an illegal relocation type:
Hardware access (read/write) watchpoint 1: *0x118b188
Old value = 8 New value = 1113968 arch_setup_gd (new_gd=0x10ff70) at arch/x86/cpu/x86_64/cpu.c:32 (gdb)
0x111173e <arch_setup_gd> mov %rdi,0x79a43(%rip) # 0x118b188
0x1111745 <arch_setup_gd+7> mov $0x20,%edi
0x111174a <arch_setup_gd+12> jmpq 0x11399fb <printch>
0x111174f <cpu_has_64bit> mov $0x1,%eax
The global_data_ptr and the relocation table occupy the same memory location:
.bss.global_data_ptr 0x000000000118b188 0x8 arch/x86/cpu/built-in.o 0x000000000118b188 global_data_ptr
.rela.got 0x000000000118b180 0x90 arch/x86/cpu/start64.o .rela.bss 0x000000000118b210 0x0 arch/x86/cpu/start64.o
Essentially we have to relocate before accessing any global symbols in the data section. I have sent a patch moving global_data_ptr to the .text section.
Best regards
Heinrich