[PATCH] Re-enable a hook in MCELFObjectTargetWriter to allow target-specific relocationtable sorting and use this hook for Mips.

[Vladimir Stefanovic]

But we are sorting the table exactly as gas only for easier comparison of the generated o files, aren't we?

The linker must not produce different results if it matches a hi with a different lo, as long as their types match (R_MIPS_HI16 with R_MIPS_LO16, etc.) and are against the same symbol.

E.g.:

0x0: lui $2,%hi(sym)
0x4: addiu $2,$2,%lo(sym)
0x8: addiu $2,$2,%lo(sym)
0xc: lui $2,%hi(sym)

The ABI and the extension allow hi at 0xc to be put before any of two lo's, and the linker must properly calculate the address in both cases. If it didn't, it would be a linker bug.

Regards,
Vladimir

________________________________________
From: Rafael Espíndola [rafael.espindola at gmail.com]
Sent: Wednesday, April 01, 2015 4:20 PM
To: reviews+D7414+public+018ed232ff71bbc8 at reviews.llvm.org
Cc: Vladimir Stefanovic; Daniel Sanders; Simon Atanasyan; Toma Tabacu; Petar Jovanovic; llvm-commits
Subject: Re: [PATCH] Re-enable a hook in MCELFObjectTargetWriter to allow target-specific relocationtable sorting and use this hook for Mips.

On 1 April 2015 at 18:26, Vladimir Stefanovic
<vladimir.stefanovic at imgtec.com> wrote:
> In http://reviews.llvm.org/D7414#150147, @rafael wrote:
>
>> > //// There may be more ways to sort the table while respecting the ABI rule;
>>
>> >  //// we always sort the same way gnu as does, for compatibility.
>>
>>
>> Still not particularly clear. We *have* to sort it in a way that
>>  causes bfd ld to match the same hi and lo relocations as would be
>>  matched had the .s been assembled by gas.
>>
>> Cheers,
>> Rafael
>
>
> Ok, a new one:
>
> // We are reusing gnu as sorting algorithm so we are emitting the relocation
> // table sorted the same way as gnu as would sort it.

It doesn't say why.

Just say that which hi and lo relocation gets matched by the linker
influences the result. The assembler then has to always make sure that
the relocations are output in an order that causes the linker to make
the same decisions as if the .o was produced by the gnu assembler.

It is horrible, but it is reality for mips.

Cheers,
Rafael