[llvm-branch-commits] MC: Emit symbols for R_X86_64_PLT32 relocation pointing to symbols with non-zero values. (PR #138795)
Fangrui Song via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Tue May 6 22:06:00 PDT 2025
MaskRay wrote:
The goal is to differentiate two scenarios when a symbol is referenced by a potential R_X86_64_PLT32 relocation:
* `.4byte foo at plt - .` (LLVM assembly extension, not supported in GNU assembler): No redirection to a thunk. References foo or its PLT entry.
* `jmp foo; .section .text.foo,"ax"; .fill 4,1,0x90; foo`: Redirect to a thunk if necessary to avoid displacement overflow.
When `foo` is local: in the `.4byte` case, Clang references `foo`, while in the `jmp foo` case, it references `.text.foo`.
When `foo` is a global or weak symbol, Clang references `foo` in both cases, making them indistinguishable to the linker.
I am still confused as to what issues this PR attempts to resolve.
Current behavior:
```
jmp foo # llvm: PLT32(.text.foo); gas: PC32(.text.foo)
jmp goo # PLT(goo)
.section .text.foo,"ax"
.fill 1, 4, 0x90
.globl goo
foo:
goo:
.data
.4byte foo at plt - . # foo
.4byte goo at plt - . # goo
```
This PR changes `jmp foo` to PLT32(foo)
When range extension thunks are implemented, and we want to support it for `.4byte foo at plt - .` (LLVM assembly extension), I think we should introduce a new relocation type.
(`R_RISCV_PLT32`, IMO, shold not following the x86 naming. `R_RISCV_PLT32_PCREL` might be better.)
https://github.com/llvm/llvm-project/pull/138795
More information about the llvm-branch-commits
mailing list