[lld] [lld] Don't drop RELR relocations for late-added GOT entries (PR #211911)

[Fangrui Song via llvm-commits]

MaskRay wrote:

> Presumably it's only the un-relaxed (as opposed to the not-relaxed) ones because, although it's dubious for addGotEntry during the normal postScanRelocations to be sharding the relocations, they'll end up in the list that hasn't yet been copied by mergeRels/finalizeSynthetic so it works out in the end, but if you're doing it post-finalize then nothing will copy them back. Yeah that won't end well.
> 
> > There is a separate unrelaxation bug where if the object files didn't have any relocations of a certain type, we'd prune .relr.dyn (or even .rela.dyn).
> 
> This sounds similar to #171475? It feels like we need a more comprehensive solution to messing with more sections in finalizeAddressDependentContent... forcing .rela.dyn and .relr.dyn to both stick around just in case is a bit of a hack that really shouldn't spread beyond PAC, especially to all architectures.

There are multiple issues in this area. `removeUnusedSyntheticSections` is called before some late  `addRelativeReloc` calls: (1) this reverted GOTPCRELX optimization instance, called by `addGotEntry`, (2) PPC64PILongBranchThunk, etc...

#96496 added an ugly condition to `removeUnusedSyntheticSections` to work around `.relr.auth.dyn`.

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