[llvm] [Object][x86-64] Add support for `R_X86_64_GLOB_DAT` relocations. (PR #103029)
Fangrui Song via llvm-commits
llvm-commits at lists.llvm.org
Tue Aug 13 21:02:27 PDT 2024
MaskRay wrote:
> > Dynamic relocation handling is completely different.
>
> Not at the level being presented here -- this is just computing relocation expressions. I guess what you mean is that dynamic expressions can depend on parameters not available in the existing `RelocationResolver` interface, e.g. `B` and `GOT`?
>
> The document you linked states:
>
> > A dynamic linker need only process dynamic relocations; a static linker must handle any defined relocation.
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).
> At least as far as that doc is concerned `RelocationResolver` should probably handle this. ;)
>
> If you want to revert while we discuss I'm fine with that. I think the discussion will depend on how many of these the Swift folks expect they'll need. If this is a one off it's fine to ask clients to handle it. If it turns out that they really need a generic relocation resolver then we can discuss what it should look like.
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 :)
https://github.com/llvm/llvm-project/pull/103029
More information about the llvm-commits
mailing list