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

[Ulrich Weigand via llvm-commits]

Rafael Espíndola <rafael.espindola at gmail.com> wrote on 16.12.2015 22:22:07:

> Are the two relocations created in the correct order? If so, we should
> probably change the default sort to use a stable sort and change the
> compare function to
>
> static int cmpRel(const ELFRelocationEntry *AP, const
> ELFRelocationEntry *BP) {
>   const ELFRelocationEntry &A = *AP;
>   const ELFRelocationEntry &B = *BP;
>   if (A.Offset != B.Offset)
>     return B.Offset - A.Offset;
>   return 0;
> }

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.

> 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.

Bye,
Ulrich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151217/32b81a4b/attachment.html>