[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