[U-Boot] [PATCH 1/1] x86: detect unsupported relocation types

[Heinrich Schuchardt]

On 10/24/2018 11:48 PM, Heinrich Schuchardt wrote:
> On 10/24/2018 08:58 PM, Hannes Schmelzer wrote:
>>> Hello Hannes,
>>>
>>> thanks for reporting the problem.
>>>
>>> There are two possible reasons:
>>>
>>> a) The build process introduces relocations of the reported type.
>>> b) The relocation records are overwritten before relocation. This
>>> happens if you update uninitialized globals.
>>>
>>> To analyze your problem further, please, provide instructions for
>>> building your version of U-Boot (repository, commit, config). That will
>>> allow to check for a).
>>>
>>> Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would
>>> allow to analyze case b). Are you able to reproduce the problem with
>>> QEMU?
>>>
>>> Best regards
>>>
>>> Heinrich
>>>
>> Hello Heinrich,
>>
>> thanks for this input.
>> The "trouble" occurs also with QEMU, have a look to console output below.
>>
>> Maybe you can investigate on this, I've pushed the branch to my github
>> account:
>>
>> https://github.com/oe5hpm/u-boot/tree/bur-next-pp065mb
>> config is "brpp065mb"
>>
>> please let me know if i can help.
>>
>> cheers,
>> Hannes
> 
> And running qemu-x86_defonfig results in
> do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff84e38,
> offset = 0xfff00091
> 
> So the problem is not restricted to your board.
> 
> I have had a first look at the relocations actually present in the
> u-boot ELF file.
> 
> Your repo:
> make brpp065mb_defconfig
> make
> objdump -r u-boot | cut -c10-20 | sort | uniq
> 
> R_386_32
> R_386_NONE
> R_386_PC32
> 
> u-boot master:
> make qemu-x86_defconfig
> make
> objdump -r u-boot | cut -c10-20 | sort | uniq
> 
> R_386_16
> R_386_32
> R_386_NONE
> R_386_PC16
> R_386_PC32
> 
> The current relocation code only supports a single relocation type
> (R_386_RELATIVE).
> 
> What I still do not understand is why most of the relocations that we
> actually see inside U-Boot are of type R_386_RELATIVE). So where are the
> relocations transformed on the way from u-boot to u-boot.bin?
> 
> The following command drops some sections and creates an image without
> any relocation information:
> 
> objcopy --gap-fill=0xff  -O binary -R .start16 -R .resetvec  u-boot
> u-boot-nodtb.bin
> 
> But where are the R_386_RELATIVEs created?
> 
> @Bin: do you have an understanding of how this works?
> 
> Best regards
> 
> Heinrich
> 

I delved a bit deeper into the biaries:

For qemu-x86_defconfig objcopy eliminates all R_386_PC32 relocations
except the last one when creating u-boot-nofdt.bin.

Hannes could you please, send me your u-boot-nodtb.bin, u-boot, and
u-boot.map. It seems my build system is not creating the relocation
record at 0x2000087 that was reported by you.

Here are the file details for qemu-x86_defconfig:


Error message:

do_elf_reloc_fixups32:
unsupported relocation type 0x2 at fff84e78, offset = 0xfff00091


objdump -drS u-boot

        call    car_uninit
fff00090:       e8 fc ff ff ff
call   fff00091 <board_init_f_r_trampoline+0xd>
                        fff00091: R_386_PC32    car_uninit
1:
        /* Re-enter U-Boot by calling board_init_f_r() */
        call    board_init_f_r
fff00095:       e8 a0 09 01 00
call   fff10a3a <board_init_f_r>
                        fff00096: R_386_PC32    board_init_f_r


Memory dump via gdb:

0xfff84e60: 0xfff73044  0x00000008  0xfff73048  0x00000008
0xfff84e70: 0xfff7304c  0x00000008  0xfff00091  0x00000102
0xfff84e80: 0xedfe0dd0  0x0b070000  0x38000000  0xd8050000
0xfff84e90: 0x28000000  0x11000000  0x10000000  0x00000000


u-boot.map

 .rel.data.test_commands
                0x00000000fff84e00       0x60 arch/x86/cpu/start.o
 .rel.u_boot_list_2_cmd_2_dm
                0x00000000fff84e60       0x20 arch/x86/cpu/start.o
                0x00000000fff84e80                __rel_dyn_end = .
                0x00000000fff84e80                . = ALIGN (0x4)
                0x00000000fff84e80                _end = .


u-boot-nodtb.bin:

00084E60   44 30 F7 FF  08 00 00 00  48 30 F7 FF  08 00 00 00
00084E70   4C 30 F7 FF  08 00 00 00  91 00 F0 FF  02 01 00 00
---  u-boot-nodtb.bin       --0x84E80/0x84E80----------------


The same trailing R_386_PC32 I could see with Hannes example:

0004CFD8   10 32 04 02  08 00 00 00  18 32 04 02  08 00 00 00
0004CFE8   24 32 04 02  08 00 00 00  28 32 04 02  08 00 00 00
0004CFF8   2C 32 04 02  08 00 00 00  91 00 00 02  02 01 00 00
---  u-boot-nodtb.bin       --0x4D008/0x4D008-------


Best regards

Heinrich