[lld] [lld] Add target support for SystemZ (s390x) (PR #75643)

[Ulrich Weigand via llvm-commits]

uweigand wrote:

I see.  I understood the `basr` trick, I just thought the overall setup was different: I thought a call to sym at PLT would always go to the .plt.got entry, which would load the target from the .got.plt entry, which would go the final target when resolved, and to the .plt entry when not - the latter would then go to the plt header which calls the glibc resolver.

However, if I understand you correctly, then .plt.got is only used if there's also a GOT entry, which is never resolved lazily and always used directly.  That's fine in this case.  (However, the optimization for this case is really independent of the other question of whether the "normal" PLT entries can be 16 or 32 bytes.)

But if there isn't a GOT entry, then a call to sym at PLT would go directly to the .plt stub, which would branch to the .got.plt entry, which I guess then always contains the PLT header address if not yet resolved lazily?   That means that there are a number of differences which could be visible to other parts of the toolchain; I think we'd need to make sure those are all understood.  As of right now, I could see:
- Even in the "fast" path (once lazy resolution has happened), we now always use basr.  This clobbers r0 - which is allowed by the ABI, but there might be some complications with other stubs maybe (e.g. mcount stubs?  we'd need to check).  Also, the basr might have performance implications as on some microarchitecture implementations it might confuse the call/return stack tracking by the branch predictor.
- glibc makes some assumptions about what target addresses the .got.plt entries contain, e.g. for the case of undoing library prelinking - this isn't frequently used anymore, but we'd still need to verify this change doesn't break anything
- The addresses in .got.plt now no longer implement the target function ABI, but implicitly require r0 and r1 to be set up correctly.  This would break "PLT inlining" via the R_390_GOTPLT family of instructions.  This is not currently used by the default toolchains, but as long as the relocations are there, I guess they need to work as expected ...

https://github.com/llvm/llvm-project/pull/75643