[BOLT][AArch64] Unknown relocation type error (R_AARCH64_P32_ABS16?) during emitAndLink with jump-table-info.s

[whubeibei]

Hi,

While testing PR #132114 (JumpTableReader support) on AArch64, I encountered a linker error related to unknown relocation types during the emitAndLink phase.

🔍 Issue
The error occurs when processing a jump table in .rodata. The relocation type reported is 2, which seems to correspond to R_AARCH64_P32_ABS16.

This happens specifically when using the bolt/test/AArch64/jump-table-info.s example included in the PR.

💻 Reproduction Steps
llvm-mc -filetype=obj -triple aarch64-unknown-unknown jump-table-info.s -o jt.o
clang jt.o jt_main.o -o jt.exe -static
clang --target=aarch64-linux-gnu -static jt.o main.o -llvm-bolt jt.exe -o /dev/null -print-jump-tables
In the final step (running BOLT), the linker reports an unknown relocation type on .rodata.

🧠 Analysis
It appears that after the jump table is recognized, BOLT emits a relocation for each entry in .rodata, which triggers the error.

I'm not familiar with how ARM relocations should be handled here — is this a missing relocation handler, or should the relocations not be emitted at all?

🗂️ Environment
Target: AArch64

Error: Unknown relocation type: 2

Possibly related relocation: R_AARCH64_P32_ABS16

PR: #132114

Any insight from ARM or BOLT maintainers would be appreciated!

Thanks,
Zichen Li

[llvmbot]

@llvm/issue-subscribers-bolt

Author: None (whubeibei)


Hi,

While testing PR #132114 (JumpTableReader support) on AArch64, I encountered a linker error related to unknown relocation types during the emitAndLink phase.

🔍 Issue
The error occurs when processing a jump table in .rodata. The relocation type reported is 2, which seems to correspond to R_AARCH64_P32_ABS16.

This happens specifically when using the bolt/test/AArch64/jump-table-info.s example included in the PR.

💻 Reproduction Steps
llvm-mc -filetype=obj -triple aarch64-unknown-unknown jump-table-info.s -o jt.o
clang jt.o jt_main.o -o jt.exe -static
clang --target=aarch64-linux-gnu -static jt.o main.o -llvm-bolt jt.exe -o /dev/null -print-jump-tables
In the final step (running BOLT), the linker reports an unknown relocation type on .rodata.

🧠 Analysis
It appears that after the jump table is recognized, BOLT emits a relocation for each entry in .rodata, which triggers the error.

I'm not familiar with how ARM relocations should be handled here — is this a missing relocation handler, or should the relocations not be emitted at all?

🗂️ Environment
Target: AArch64

Error: Unknown relocation type: 2

Possibly related relocation: R_AARCH64_P32_ABS16

PR: #132114

Any insight from ARM or BOLT maintainers would be appreciated!

Thanks,
Zichen Li

[aaupov]

@paschalis-mpeis, can you please check what relocation is that, and if it's supported by BOLT?

[paschalis-mpeis]

I believe @yavtuk said he has some work towards this. In which case he can proceed with a PR?

[yavtuk]

@whubeibei hello, can you check MR or provide reproducer ?

[yavtuk]

@whubeibei Sorry, I missed the message with the reproducer, I will check and let you know soon

[yavtuk]

@whubeibei I check relocations, issue fixed,

please take this MR (#143773)

I think you need to check JumpTable::updateOriginal function and type of relocations

llvm-project/bolt/lib/Core/JumpTable.cpp

Line 82 in 0e45731

void bolt::JumpTable::updateOriginal() {

[whubeibei]

@whubeibei I check relocations, issue fixed,

please take this MR (#143773)

I think you need to check JumpTable::updateOriginal function and type of relocations

llvm-project/bolt/lib/Core/JumpTable.cpp

Line 82 in 0e45731

void bolt::JumpTable::updateOriginal() {

Thanks again for the fix and your guidance!

While reviewing the code, I noticed that JumpTable::updateOriginal() still hardcodes x86_64-specific relocation types like R_X86_64_64 and R_X86_64_PC32, regardless of the target architecture.

If this function is ever used on AArch64 targets (e.g., via JumpTableReader recognizing .rodata jump tables), it may emit incorrect relocation types, which could cause similar issues down the road — especially since the current logic doesn't check Triple::isAArch64() or support AArch64-specific relocation enums like R_AARCH64_P32_ABS32.

Would it make sense to make this function architecture-aware, or at least guard it against being called on unsupported targets?

I'm still fairly new to BOLT and its internals, so please let me know if I misunderstood anything — I'm eager to learn and happy to assist where I can.

[yavtuk]

This function is used because in this test binary there is jump table and by default jump table type is Normal. It's possible to add arch independent relocation there, getAbs64() or another one, depends on the pattern of JT

[paschalis-mpeis]

I think this is now resolved. PR #132114 is WIP and currently not handling AArch64 (1, 2, 3).

Thank you both @whubeibei and @yavtuk!

[aaupov]

I think this is now resolved. PR #132114 is WIP and currently not handling AArch64 (1, 2, 3).

Thank you both @whubeibei and @yavtuk!

For clarity: that PR is not standalone, but is part of the stack:
#132109
#132110
#132113
#132114
#135103

That should provide a basic support for jump tables with .jump_table_info section. However, it's known to have issues which is why it's still not merged.
I switched away from this effort for now. I would be happy if you take over this work.

[whubeibei]

I think this is now resolved. PR #132114 is WIP and currently not handling AArch64 (1, 2, 3).
Thank you both @whubeibei and @yavtuk!

For clarity: that PR is not standalone, but is part of the stack. ARM jump table types are added in #132109. However we decided not to use architecture-specific types, so the PRs need updating. I switched away from this effort for now.

Thanks for your previous work on AArch64 jump table support — I’m interested in continuing this effort.

To get a better understanding of the current status, could you please clarify:

What parts of the AArch64 jump table support are already implemented or partially done?

Are there any key blockers or design decisions I should be aware of before continuing?

Would it be better to revise the existing PRs (like #132109 / #132114) or start a new one aligned with the decision to avoid architecture-specific JT types?

I'd be happy to take over and update the implementation according to the current community direction. Let me know what you think — and thank you again for your guidance!