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

[Alastair Houghton via llvm-commits]

al45tair wrote:

I did think about this a bit before making the PR in the first place. As Lang says, the issue here is with a tool that statically inspects metadata within a Swift-compiled binary. Newer versions of LLVM changed the way some of the relocations are generated on x86-64 and started emitting `GLOB_DAT` relocations where previously it didn't, which broke the tool because it relies on `RelocationResolver`.

Now, it is true that the tool already handles `RELATIVE` itself (which it has to, because the `RelocationResolver` doesn't have enough parameters to get the correct result in that case — this is also true, of course, for many of the other dynamic relocation types), and it _could_ likewise handle `GLOB_DAT`.

However, I don't think handling `GLOB_DAT` relocations needs any extra arguments to the `RelocationResolver` function; they're for setting the GOT entries to the address of a particular symbol, and `S` is already an argument to `RelocationResolver` so there's no _technical_ reason to prefer _not_ supporting it here, and adding support to `RelocationResolver` is a trivial three line change, versus a slightly larger change in the reflection dump tool (and then again in any other tool that finds itself similarly needing to read addresses from the GOT). As for whether to support `JMP_SLOT` too, I didn't do that because we don't need it here — and I think in general tools that inspect data held in sections in executable images are less likely to need `JMP_SLOT` support. Tools that _do_ want `JMP_SLOT` support are likely doing code analysis and will probably not be leaning on LLVM infrastructure when doing that anyway.

The argument seems to be more philosophical and hinges on whether or not `RelocationResolver` should support _any_ dynamic relocations, even ones it could reasonably compute with the data it has. I don't have a particularly strong view on that — just in this particular case I came down on the side of "it can compute this easily, there are likely other tools that will have the same problem, so fixing upstream in LLVM makes sense".

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