[llvm] [Object][x86-64] Add support for `R_X86_64_GLOB_DAT` relocations. (PR #103029)

[Lang Hames via llvm-commits]

lhames wrote:

> I'll try fixing this sentence as it doesn't match the practice and all the existing ELF linkers.
Link editors don't handle dynamic-only relocations (RELATIVE, GLOB_DAT, JUMP_SLOT, IRELATIVE, etc).
>
> edit: The sentence probably should be read as: static linkers need to process static relocations and produce dynamic relocations. The sentence isn't clear about whether dynamic relocations should be handled as input.

Yep. It's probably worth rewording, but FWIW the way I thought of it was: static _tooling_ should be able to handle dynamic relocations, e.g. for dumping linked images.

> It's not only Swift, also whether the API is correctly exposed. (a) RelocationResolver isn't for dynamic relocations (b) Swift really could support GLOB_DAT in its own code and should support GLOB_DAT for all supported architectures.
I'll keep commenting until I convince you that adding GLOB_DAT to RelocationResolver isn't the right thing :)

Those are declarations, I'd like to see a _reason_ if you want to convince me. ;)

My pitch: it's perfectly reasonable to have _an_ API in LLVM that can handle dynamic relocations, and that utility is going to look an _awful_ lot like `RelocationResolver`, just with a couple of different parameters. Whether we have one utility or two doesn't bother me, though it would be nice to avoid duplicating the expressions if we can avoid it.

Clients (including Swift) certainly _could_ support `GLOB_DAT` directly, but if there's a wider dynamic relocation support is needed then I think it makes sense for LLVM to provide that (and our own static tools might make use of it).

This does hinge on whether wider support is needed -- if this is a one-off then asking Swift to special-case it seems fine.

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