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

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

The SystemZ linkers provide an optimization to transform a general-
or local-dynamic TLS sequence into an initial-exec sequence if possible.
Do do that, the compiler generates a function call to __tls_get_offset,
which is a brasl instruction annotated with *two* relocations:

- a R_390_PLT32DBL to install __tls_get_offset as branch target
- a R_390_TLS_GDCALL / R_390_TLS_LDCALL to inform the linker that
  the TLS optimization should be performed if possible

If the optimization is performed, the brasl is replaced by an ld load
instruction.

However, *both* relocs are processed independently by the linker.
Therefore it is crucial that the R_390_PLT32DBL is processed *first*
(installing the branch target for the brasl) and the R_390_TLS_GDCALL
is processed *second* (replacing the whole brasl with an ld).

If the relocs are swapped, the linker will first replace the brasl
with an ld, and *then* install the __tls_get_offset branch target
offset.  Since ld has a different layout than brasl, this may even
result in a completely different (or invalid) instruction; in any
case, the resulting code is corrupted.

Unfortunately, the way the MC common code sorts relocations causes
these two to *always* end up the wrong way around, resulting in
wrong code generation by the linker and crashes.

This patch overrides the sortRelocs routine to detect this particular
pair of relocs and enforce the required order.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255787 91177308-0d34-0410-b5e6-96231b3b80d8