This is the mail archive of the
mailing list for the binutils project.
RE: binutils/ld: "Sort relocs output by ld -r" breaks mips cross compilation of linux
- From: Andrew Bennett <Andrew dot Bennett at imgtec dot com>
- To: Manuel Lauss <manuel dot lauss at gmail dot com>, Alan Modra <amodra at gmail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 8 Dec 2014 15:33:45 +0000
- Subject: RE: binutils/ld: "Sort relocs output by ld -r" breaks mips cross compilation of linux
- Authentication-results: sourceware.org; auth=none
- References: <CAOLZvyGoKxxrCC5XJ52jB=dgv1qFEE5njFRRY6-h+dcfOvyZhw at mail dot gmail dot com>
> your patch to binutils/ld "Sort relocs output by ld -r" causes a lot of
> the following warnings when I cross-compile the linux kernel for
> little-endian mips32 on an x64 host:
> mipsel-softfloat-linux-gnu-ld: init/mounts.o: Can't find matching LO16
> reloc against `$LC2' for R_MIPS_HI16 at 0x4e8 in section `.text'
> If I revert that patch the kernel build succeeds without warnings and boots.
> (I wrongly blamed a patch by Andrew Bennett before which turns out
> to be innocent).
It is probably best to explain why this causes the issue, so I have explained
it in more detail below:
The MIPS HI16/LO16 relocations must occur in pairs. This means the LO16
relocation must occur directly after the HI16 relocation in the relocation table.
If we look at an example that was found in the Linux build. The original
elf file had the relocations in the following order.
00000514 00005f05 R_MIPS_HI16 00000000 block_class
00000458 00005f05 R_MIPS_HI16 00000000 block_class
00000460 00005f06 R_MIPS_LO16 00000000 block_class
But these became the following when -r is used:
00000458 00005705 R_MIPS_HI16 00000000 block_class
0000045c 00000305 R_MIPS_HI16 00000000 .text
00000460 00005706 R_MIPS_LO16 00000000 block_class
00000514 00005705 R_MIPS_HI16 00000000 block_class
Therefore when the HI16/LO16 relocation checking is done for the block_class
symbol it will be unable to find the corresponding LO16 relocation in the
second instance, which is why Manuel was getting error messages about