[U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing

[Heinrich Schuchardt]

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 at 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 at 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 at 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