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

[Bin Meng]

Hi Heinrich,

On Thu, Oct 25, 2018 at 5:48 AM Heinrich Schuchardt <xypron.glpk at gmx.de> 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:
>

No, the following command only remove the 16-bit codes from the u-boot
image. Other sections are untouched.

> objcopy --gap-fill=0xff  -O binary -R .start16 -R .resetvec  u-boot
> u-boot-nodtb.bin
>
> But where are the R_386_RELATIVEs created?
>

It's in the u-boot.bin image. We don't touch it during the build process.

> @Bin: do you have an understanding of how this works?
>

Regards,
Bin