This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: binutils/ld: "Sort relocs output by ld -r" breaks mips cross compilation of linux


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]