[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