This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: binutils/ld: "Sort relocs output by ld -r" breaks mips cross compilation of linux
- From: Manuel Lauss <manuel dot lauss at gmail dot com>
- To: Andrew Bennett <Andrew dot Bennett at imgtec dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, Alan Modra <amodra at gmail dot com>
- Date: Tue, 9 Dec 2014 08:28:44 +0100
- 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> <0DA23CC379F5F945ACB41CF394B9827720F3FA8E at LEMAIL01 dot le dot imgtec dot org> <20141209012126 dot GC31968 at bubble dot grove dot modra dot org>
On Tue, Dec 9, 2014 at 2:21 AM, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Dec 08, 2014 at 03:33:45PM +0000, Andrew Bennett wrote:
>> > 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
>> missing relocations.
>
> Blah. I sorted external relocs rather than internal just for mips,
> otherwise a non-stable qsort might reorder within the abominable
> 3-for-1 internal relocs. I didn't remember that mips deliberately
> puts relocs out of r_offset order as per the mips ABI.
>
> The following ought to fix it. Please review the mips changes and let
> me know if they are good.
This patch works fine, kernel builds and boots.
Thank you!
Manuel Lauss