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

[Heinrich Schuchardt]

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