[llvm] [X86] Disallow immediate address calls when position independent (PR #202370)

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 9 19:00:21 PDT 2026


================
@@ -241,7 +241,7 @@ bool X86Subtarget::isLegalToCallImmediateAddr() const {
   // FIXME: I386 PE/COFF supports PC relative calls using IMAGE_REL_I386_REL32
   // but WinCOFFObjectWriter::RecordRelocation cannot emit them.  Once it does,
   // the following check for Win32 should be removed.
-  if (Is64Bit || isTargetWin32())
+  if (Is64Bit || isTargetWin32() || isPositionIndependent())
----------------
rui314 wrote:

Here is a simple C reproducer.

```bash
#!/bin/bash
cat <<EOF > test.c
void call_fixed_addr(void) {
  ((void (*)(void))0x1000)();
}
EOF

clang -m32 -c -fPIC -O2 -o test-clang.o test.c
gcc   -m32 -c -fPIC -O2 -o test-gcc.o   test.c

objdump -dr test-clang.o
objdump -dr test-gcc.o
```

Here is the objdump output for clang and gcc.

```
00000000 <call_fixed_addr>:
   0:   53                      push   %ebx
   1:   83 ec 08                sub    $0x8,%esp
   4:   e8 00 00 00 00          call   9 <call_fixed_addr+0x9>
   9:   5b                      pop    %ebx
   a:   81 c3 03 00 00 00       add    $0x3,%ebx
                        c: R_386_GOTPC  _GLOBAL_OFFSET_TABLE_
  10:   e8 fc 0f 00 00          call   1011 <call_fixed_addr+0x1011>
                        11: R_386_PC32  *ABS*
  15:   83 c4 08                add    $0x8,%esp
  18:   5b                      pop    %ebx
  19:   c3                      ret

00000000 <call_fixed_addr>:
   0:   b8 00 10 00 00          mov    $0x1000,%eax
   5:   ff e0                   jmp    *%eax
```

Clang emits an unrepresentable relocation for the instruction at 0x10. Moreover, it emits unnecessary code before that to set up %ebx to hold the address of the GOT, probably because it misunderstands that the call might go through the PLT (the i386 psABI requires %ebx to point to the beginning of the GOT when control reaches a PLT entry).

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


More information about the llvm-commits mailing list