[llvm] r255787 - [SystemZ] Sort relocs to avoid code corruption by linker optimization

[Rafael Espíndola via llvm-commits]

> The relocation are created in the correct order, but the above would not
> help, since the two relocations are at *different* offsets; but sorting
> by offset arranges them in exactly the wrong order.
>
> There is a R_390_PLT32DBL at offset 2 in the insn (at the offset field),
> which must come first, and there is a R_390_TLS_GDCALL at offset 0 in
> the insn, which must come second.

I see, thanks.

>> The function is there just for bug by bug compatibility with gas and
>> as an easy hack for making the output stable. Ideally we just just
>> delete it and fix any non deterministic code.
>
> What gas does on s390x is to sort relocs for data sections (which is
> required at least for .eh_frame as I understand), but does not sort
> relocs for code sections.

But those are also create in the correct order.

Now that we store the relocations in a deterministic way, the only
thing that was actually requiring sorting was MIPS crazy HI/LO
pairing. If simplified the code in r255902.

Cheers,
Rafael