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.g...@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...@gmail.com> wrote:
>>>>>
>>>>> Add qemu-x86_64 to the list of targets we use for test.py runs.
>>>>>
>>>>> Signed-off-by: Bin Meng <bmeng...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
