[bolt][aarch64] Add R_AARCH64_P32_ABS16/32 relocations #143773

yavtuk · 2025-06-11T19:42:21Z

Added few relocations for quick checking

llvmbot · 2025-06-11T19:42:53Z

@llvm/pr-subscribers-bolt

Author: Alexey Moksyakov (yavtuk)

Changes

Added few relocations for quick checking

Full diff: https://github.com/llvm/llvm-project/pull/143773.diff

2 Files Affected:

(modified) bolt/lib/Core/Relocation.cpp (+10)
(modified) bolt/lib/Target/AArch64/AArch64MCPlusBuilder.cpp (+2)

diff --git a/bolt/lib/Core/Relocation.cpp b/bolt/lib/Core/Relocation.cpp
index f099dfa46f3d4..c189dbe8f49fd 100644
--- a/bolt/lib/Core/Relocation.cpp
+++ b/bolt/lib/Core/Relocation.cpp
@@ -87,7 +87,9 @@ static bool isSupportedAArch64(uint32_t Type) {
   case ELF::R_AARCH64_PREL32:
   case ELF::R_AARCH64_PREL64:
   case ELF::R_AARCH64_ABS16:
+  case ELF::R_AARCH64_P32_ABS16:
   case ELF::R_AARCH64_ABS32:
+  case ELF::R_AARCH64_P32_ABS32:
   case ELF::R_AARCH64_ABS64:
   case ELF::R_AARCH64_MOVW_UABS_G0:
   case ELF::R_AARCH64_MOVW_UABS_G0_NC:
@@ -167,6 +169,7 @@ static size_t getSizeForTypeAArch64(uint32_t Type) {
     errs() << object::getELFRelocationTypeName(ELF::EM_AARCH64, Type) << '\n';
     llvm_unreachable("unsupported relocation type");
   case ELF::R_AARCH64_ABS16:
+  case ELF::R_AARCH64_P32_ABS16:
   case ELF::R_AARCH64_PREL16:
     return 2;
   case ELF::R_AARCH64_CALL26:
@@ -204,6 +207,7 @@ static size_t getSizeForTypeAArch64(uint32_t Type) {
   case ELF::R_AARCH64_MOVW_UABS_G2_NC:
   case ELF::R_AARCH64_MOVW_UABS_G3:
   case ELF::R_AARCH64_ABS32:
+  case ELF::R_AARCH64_P32_ABS32:
   case ELF::R_AARCH64_PLT32:
     return 4;
   case ELF::R_AARCH64_ABS64:
@@ -290,7 +294,9 @@ static uint64_t encodeValueAArch64(uint32_t Type, uint64_t Value, uint64_t PC) {
   default:
     llvm_unreachable("unsupported relocation");
   case ELF::R_AARCH64_ABS16:
+  case ELF::R_AARCH64_P32_ABS16:
   case ELF::R_AARCH64_ABS32:
+  case ELF::R_AARCH64_P32_ABS32:
   case ELF::R_AARCH64_ABS64:
     break;
   case ELF::R_AARCH64_PREL16:
@@ -352,7 +358,9 @@ static uint64_t extractValueAArch64(uint32_t Type, uint64_t Contents,
     errs() << object::getELFRelocationTypeName(ELF::EM_AARCH64, Type) << '\n';
     llvm_unreachable("unsupported relocation type");
   case ELF::R_AARCH64_ABS16:
+  case ELF::R_AARCH64_P32_ABS16:
   case ELF::R_AARCH64_ABS32:
+  case ELF::R_AARCH64_P32_ABS32:
   case ELF::R_AARCH64_ABS64:
     return Contents;
   case ELF::R_AARCH64_PREL16:
@@ -643,7 +651,9 @@ static bool isPCRelativeAArch64(uint32_t Type) {
   default:
     llvm_unreachable("Unknown relocation type");
   case ELF::R_AARCH64_ABS16:
+  case ELF::R_AARCH64_P32_ABS16:
   case ELF::R_AARCH64_ABS32:
+  case ELF::R_AARCH64_P32_ABS32:
   case ELF::R_AARCH64_ABS64:
   case ELF::R_AARCH64_LDST64_ABS_LO12_NC:
   case ELF::R_AARCH64_ADD_ABS_LO12_NC:
diff --git a/bolt/lib/Target/AArch64/AArch64MCPlusBuilder.cpp b/bolt/lib/Target/AArch64/AArch64MCPlusBuilder.cpp
index eb1d9d8a19514..f12ff033ca3ff 100644
--- a/bolt/lib/Target/AArch64/AArch64MCPlusBuilder.cpp
+++ b/bolt/lib/Target/AArch64/AArch64MCPlusBuilder.cpp
@@ -2244,7 +2244,9 @@ class AArch64MCPlusBuilder : public MCPlusBuilder {
     switch (RelType) {
     case ELF::R_AARCH64_ABS64:
     case ELF::R_AARCH64_ABS32:
+    case ELF::R_AARCH64_P32_ABS32:
     case ELF::R_AARCH64_ABS16:
+    case ELF::R_AARCH64_P32_ABS16:
     case ELF::R_AARCH64_ADD_ABS_LO12_NC:
     case ELF::R_AARCH64_ADR_GOT_PAGE:
     case ELF::R_AARCH64_ADR_PREL_LO21:

yavtuk · 2025-06-11T19:43:38Z

Related Issue #143709

paschalis-mpeis

Hey Alexei,

Thanks for the patch! The code itself looks okay. When trying @aaupov patch #132114 (currently marked as draft), I do get a failure on AArch64/jump-table-info.s as @whubeibei reports on issue #143709.

After cherry-picking this PR on top of Amir's draft PR I get an assertion:

BinarySection.cpp:136: void llvm::bolt::BinarySection::emitAsData(MCStreamer &, const Twine &) const
: Assertion `SectionOffset <= SectionContents.size() && "overflow error"' failed.

Not sure if I missed something.

Regarding the relocations themselves, they appear to be part of the ILP32 which is Beta. @yavtuk , @whubeibei could you share more details on how you get to generate those relocations in the input binary?

cc @smithp35 who can provide additional context around the status of ILP32.

yavtuk · 2025-06-12T09:34:32Z

This assert is not related to the type of relocations, I added the link to source code where I think the problem is. There emit Jump Table function where you can find updateOriginal entry and there we should add relocation for aarch64 platform

yavtuk · 2025-06-12T09:36:56Z

I think this relocations are generated by mistake, the one for x86 type in emitJumpTables function. I had the one before I added abs64 relocation correctly for aarch64

paschalis-mpeis · 2025-06-12T09:41:12Z

This assert is not related to the type of relocations, I added the link to source code where I think the problem is. There emit Jump Table function where you can find updateOriginal entry and there we should add relocation for aarch64 platform

Yes, I agree. The patch itself looks good; it only needs tests. Maybe that is what you meant here.

I think this relocations are generated by mistake, the one for x86 type in emitJumpTables function. I had the one before I added abs64 relocation correctly for aarch64

Yeap, and that is my concern for supporting these beta relocations in BOLT.

whubeibei · 2025-06-12T09:49:11Z

Hey Alexei,

Thanks for the patch! The code itself looks okay. When trying @aaupov patch #132114 (currently marked as draft), I do get a failure on AArch64/jump-table-info.s as @whubeibei reports on issue #143709.

After cherry-picking this PR on top of Amir's draft PR I get an assertion:
BinarySection.cpp:136: void llvm::bolt::BinarySection::emitAsData(MCStreamer &, const Twine &) const
: Assertion `SectionOffset <= SectionContents.size() && "overflow error"' failed.
Not sure if I missed something.

Regarding the relocations themselves, they appear to be part of the ILP32 which is Beta. @yavtuk , @whubeibei could you share more details on how you get to generate those relocations in the input binary?

cc @smithp35 who can provide additional context around the status of ILP32.

Thanks for the update!

I only applied PR #132114 along with its prerequisite patch (#131997), and I haven't encountered the emitAsData() assertion so far.

That said, I'm still learning the internals of BOLT and AArch64 relocation handling, and I'm trying to understand the cause of this issue. I'll keep digging and follow up if I find anything useful.

Hey Alexei,

Thanks for the patch! The code itself looks okay. When trying @aaupov patch #132114 (currently marked as draft), I do get a failure on AArch64/jump-table-info.s as @whubeibei reports on issue #143709.

After cherry-picking this PR on top of Amir's draft PR I get an assertion:
BinarySection.cpp:136: void llvm::bolt::BinarySection::emitAsData(MCStreamer &, const Twine &) const
: Assertion `SectionOffset <= SectionContents.size() && "overflow error"' failed.
Not sure if I missed something.

Regarding the relocations themselves, they appear to be part of the ILP32 which is Beta. @yavtuk , @whubeibei could you share more details on how you get to generate those relocations in the input binary?

cc @smithp35 who can provide additional context around the status of ILP32.

Thanks for the update!

I only applied PR #132114 along with its prerequisite patch , and I haven't encountered the emitAsData() assertion so far.

That said, I'm still learning the internals of BOLT and AArch64 relocation handling, and I'm trying to understand the cause of this issue. I'll keep digging and follow up if I find anything useful.

As for the relocations, I also believe—like @yavtuk mentioned—that they were generated by mistake. It seems emitJumpTables() and updateOriginal() are still using hardcoded x86 relocation types, which causes problems on AArch64. Adding proper relocation types for AArch64 in those places might be the right direction, and I'm planning to look into that.

Thanks again for all the insights and help!

smithp35 · 2025-06-12T09:51:01Z

The ILP32 relocation codes are only legal in ELFCLASS32 files https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#5731relocation-names-and-class

I recommend that you add these only if you are intending to support 32-bit ILP32 files in BOLT (presumably from a GCC ILP32 toolchain). An ELFCLASS64 file containing these relocations is not well defined as there are different codes for the same relocation in AArch64. Is it possible that someone used the ILP32 value for the relocation code (< 256) rather than the usual one https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#575static-data-relocations

yavtuk · 2025-06-12T09:53:51Z

@smithp35 we are not going to merge this code to main branch because this relocations are generated by mistake, I will close this MR soon, just to show that we made mistake in another place

paschalis-mpeis · 2025-06-12T09:53:55Z

@yavtuk, @whubeibei okay, just to clarify, these relocations aren't present in the input binary, but generated by mistake as the below code is not guarded for AArch64?

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

Lines 86 to 91 in d49a2b5

    
           for (MCSymbol *Entry : Entries) { 
        
             const uint64_t RelType = 
        
                 Type == JTT_X86_64_ABS ? ELF::R_X86_64_64 : ELF::R_X86_64_PC32; 
        
             const uint64_t RelAddend = 
        
                 Type == JTT_X86_64_ABS ? 0 : EntryOffset - BaseOffset; 
        
             // Replace existing relocation with the new one to allow any modifications

And this happens only because the encoding of X86:

llvm-project/llvm/include/llvm/BinaryFormat/ELFRelocs/x86_64.def

Lines 7 to 8 in ab4e066

    
           ELF_RELOC(R_X86_64_64,          1) 
        
           ELF_RELOC(R_X86_64_PC32,        2)

happens to map on these on AArch64 relocations?

llvm-project/llvm/include/llvm/BinaryFormat/ELFRelocs/AArch64.def

Lines 170 to 171 in a9ad9e2

    
           ELF_RELOC(R_AARCH64_P32_ABS32,                       0x001) 
        
           ELF_RELOC(R_AARCH64_P32_ABS16,                       0x002)

If that is the case then maybe we don't need to proceed with this patch, at least not at this point.

whubeibei · 2025-06-12T10:07:53Z

@yavtuk, @whubeibei okay, just to clarify, these relocations aren't present in the input binary, but generated by mistake as the below code is not guarded for AArch64?

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

Lines 86 to 91 in d49a2b5

for (MCSymbol *Entry : Entries) {

const uint64_t RelType =

Type == JTT_X86_64_ABS ? ELF::R_X86_64_64 : ELF::R_X86_64_PC32;

const uint64_t RelAddend =

Type == JTT_X86_64_ABS ? 0 : EntryOffset - BaseOffset;

// Replace existing relocation with the new one to allow any modifications

And this happens only because the encoding of X86:

llvm-project/llvm/include/llvm/BinaryFormat/ELFRelocs/x86_64.def

Lines 7 to 8 in ab4e066

ELF_RELOC(R_X86_64_64, 1)

ELF_RELOC(R_X86_64_PC32, 2)

happens to map on these on AArch64 relocations?

llvm-project/llvm/include/llvm/BinaryFormat/ELFRelocs/AArch64.def

Lines 170 to 171 in a9ad9e2

ELF_RELOC(R_AARCH64_P32_ABS32, 0x001)

ELF_RELOC(R_AARCH64_P32_ABS16, 0x002)

If that is the case then maybe we don't need to proceed with this patch, at least not at this point.

yes，i think it's a mistake

paschalis-mpeis · 2025-06-12T11:33:57Z

I'd say it's more that this PR is still unfinished :)

[BOLT][AArch64] Add jump table support using .llvm_jump_table_info #132114

Mystery solved then. Τhanks for being keen and trying it out! Would you mind if I go ahead and close #143709 ?

BTW, @aaupov is the diff rendering properly here?

https://github.com/llvm/llvm-project/pull/132114/files

When I pull that PR locally I see changes on 17 files, including JumpTable.cpp, but online I only see 7 changed files.

yavtuk · 2025-06-12T11:37:22Z

I'd say it's more that this PR is still unfinished :)

[BOLT][AArch64] Add jump table support using .llvm_jump_table_info #132114

Mystery solved then. Τhanks for being keen and trying it out! Would you mind if I go ahead and close #143709 ?

BTW, @aaupov is the diff rendering properly here?

https://github.com/llvm/llvm-project/pull/132114/files

When I pull that PR locally I see changes on 17 files, including JumpTable.cpp, but online I only see 7 changed files.

I agree with closing about #143709

whubeibei · 2025-06-12T11:41:20Z

I'd say it's more that this PR is still unfinished :)

[BOLT][AArch64] Add jump table support using .llvm_jump_table_info #132114

Mystery solved then. Τhanks for being keen and trying it out! Would you mind if I go ahead and close #143709 ?

BTW, @aaupov is the diff rendering properly here?

https://github.com/llvm/llvm-project/pull/132114/files

When I pull that PR locally I see changes on 17 files, including JumpTable.cpp, but online I only see 7 changed files.

Thanks! Sure, feel free to close #143709 — it was mainly for debugging purposes to surface the issue. I'd be happy to help test or contribute toward #132114 for a complete fix for jump table handling.

whubeibei · 2025-06-12T11:56:07Z

I'd say it's more that this PR is still unfinished :)

[BOLT][AArch64] Add jump table support using .llvm_jump_table_info #132114

Mystery solved then. Τhanks for being keen and trying it out! Would you mind if I go ahead and close #143709 ?
BTW, @aaupov is the diff rendering properly here?

https://github.com/llvm/llvm-project/pull/132114/files

When I pull that PR locally I see changes on 17 files, including JumpTable.cpp, but online I only see 7 changed files.

I agree with closing about #143709

thanks for your earlier comment!

based on the jump table support introduced in PR #132114.

As we noted, BOLT attempts to generate relocations for jump table entries, but currently there is no suitable relocation type for these entries on AArch64.

Since I’m still not very familiar with BOLT internals and ARM architecture specifics, I would like to seek more detailed guidance on how to properly improve or extend the implementation to handle this case.

Specifically:

Should we define a new AArch64 relocation type within BOLT for jump table entries?
Or is there an alternative approach recommended for jump tables using .byte offset entries without relocations?
Or are there any other best practices or existing mechanisms in BOLT that I might have overlooked?

I’m eager to learn and contribute to the fix once I better understand the recommended path forward.

Thank you very much for your advice and help!

yavtuk · 2025-06-12T12:05:31Z

I'd say it's more that this PR is still unfinished :)

[BOLT][AArch64] Add jump table support using .llvm_jump_table_info #132114

Mystery solved then. Τhanks for being keen and trying it out! Would you mind if I go ahead and close #143709 ?
BTW, @aaupov is the diff rendering properly here?

https://github.com/llvm/llvm-project/pull/132114/files

When I pull that PR locally I see changes on 17 files, including JumpTable.cpp, but online I only see 7 changed files.

I agree with closing about #143709

thanks for your earlier comment!

based on the jump table support introduced in PR #132114.

As we noted, BOLT attempts to generate relocations for jump table entries, but currently there is no suitable relocation type for these entries on AArch64.

Since I’m still not very familiar with BOLT internals and ARM architecture specifics, I would like to seek more detailed guidance on how to properly improve or extend the implementation to handle this case.

Specifically:

Should we define a new AArch64 relocation type within BOLT for jump table entries?

No, we just need to emit entry as symbol which should be encoded according to JT pattern

Or is there an alternative approach recommended for jump tables using .byte offset entries without relocations?

Or are there any other best practices or existing mechanisms in BOLT that I might have overlooked?

I’m eager to learn and contribute to the fix once I better understand the recommended path forward.

Thank you very much for your advice and help!

I implemented JT for aarch64 but for GCC, I will help you here, we have a holidaynow but on the next week I will try to resolve this complicated moment

whubeibei · 2025-06-12T12:13:56Z

I'd say it's more that this PR is still unfinished :)

[BOLT][AArch64] Add jump table support using .llvm_jump_table_info #132114

Mystery solved then. Τhanks for being keen and trying it out! Would you mind if I go ahead and close #143709 ?
BTW, @aaupov is the diff rendering properly here?

https://github.com/llvm/llvm-project/pull/132114/files

When I pull that PR locally I see changes on 17 files, including JumpTable.cpp, but online I only see 7 changed files.

I agree with closing about #143709

thanks for your earlier comment!
based on the jump table support introduced in PR #132114.
As we noted, BOLT attempts to generate relocations for jump table entries, but currently there is no suitable relocation type for these entries on AArch64.
Since I’m still not very familiar with BOLT internals and ARM architecture specifics, I would like to seek more detailed guidance on how to properly improve or extend the implementation to handle this case.
Specifically:

Should we define a new AArch64 relocation type within BOLT for jump table entries?

No, we just need to emit entry as symbol which should be encoded according to JT pattern

Or is there an alternative approach recommended for jump tables using .byte offset entries without relocations?

Or are there any other best practices or existing mechanisms in BOLT that I might have overlooked?

I’m eager to learn and contribute to the fix once I better understand the recommended path forward.
Thank you very much for your advice and help!

I implemented JT for aarch64 but for GCC, I will help you here, we have a holidaynow but on the next week I will try to resolve this complicated moment

Thanks a lot for your quick reply and explanation!

I get that we don’t need new relocation types, and the jump table entries should just be emitted as symbols following the JT pattern.

Really appreciate that you’re willing to help with the AArch64 jump table stuff based on your GCC work. Enjoy your holiday, and I’m looking forward to working with you when you’re back.

If you have any docs or example code about the JT pattern or symbol encoding, could you please share? I’d like to start getting familiar with it while waiting.

Thanks again for your help!

[bolt][aarch64] Add P32_ABS16/32 relocations

91cb75f

yavtuk requested review from aaupov, maksfb, rafaelauler, ayermolo, yota9 and paschalis-mpeis as code owners June 11, 2025 19:42

llvmbot added the BOLT label Jun 11, 2025

yavtuk mentioned this pull request Jun 11, 2025

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

Closed

yavtuk changed the title ~~Draft: [bolt][aarch64] Add P32_ABS16/32 relocations~~ [bolt][aarch64] Add P32_ABS16/32 relocations Jun 11, 2025

yavtuk changed the title ~~[bolt][aarch64] Add P32_ABS16/32 relocations~~ [bolt][aarch64] Add R_AARCH64_P32_ABS16/32 relocations Jun 11, 2025

paschalis-mpeis reviewed Jun 12, 2025

View reviewed changes

yavtuk closed this Jun 13, 2025

[bolt][aarch64] Add R_AARCH64_P32_ABS16/32 relocations #143773

[bolt][aarch64] Add R_AARCH64_P32_ABS16/32 relocations #143773

Uh oh!

Conversation

yavtuk commented Jun 11, 2025

Uh oh!

llvmbot commented Jun 11, 2025

Uh oh!

yavtuk commented Jun 11, 2025

Uh oh!

paschalis-mpeis left a comment

Choose a reason for hiding this comment

Uh oh!

yavtuk commented Jun 12, 2025

Uh oh!

yavtuk commented Jun 12, 2025

Uh oh!

paschalis-mpeis commented Jun 12, 2025

Uh oh!

whubeibei commented Jun 12, 2025

Uh oh!

smithp35 commented Jun 12, 2025

Uh oh!

yavtuk commented Jun 12, 2025

Uh oh!

paschalis-mpeis commented Jun 12, 2025

Uh oh!

whubeibei commented Jun 12, 2025

Uh oh!

paschalis-mpeis commented Jun 12, 2025

Uh oh!

yavtuk commented Jun 12, 2025

Uh oh!

whubeibei commented Jun 12, 2025

Uh oh!

whubeibei commented Jun 12, 2025

Uh oh!

yavtuk commented Jun 12, 2025

Uh oh!

whubeibei commented Jun 12, 2025

Uh oh!

Uh oh!