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

[Bin Meng]

Hi Heinrich,

On Thu, Oct 25, 2018 at 2:25 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> 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-------

There is a bug in the start.S. I will send a patch soon.

Regards,
Bin