[AArch64] Unconditionally use DW_EH_PE_indirect|DW_EH_PE_pcrel personality/lsda/ttype encodings

[MaskRay]

Summary

For -fno-pic, without DW_EH_PE_indirect, the personality routine pointer in a
CIE needs an R_AARCH64_ABS64 relocation. In common configurations that
__gcc_personality_v0 is defined in a shared object, this will lead to a
discouraged canonical PLT entry, or, if ld.lld -z notext (betwen D122459 and
D143136), a dynamic R_AARCH64_ABS64 relocation with an incorrect offset:
https://github.com/llvm/llvm-project/issues/60392

Since GCC uses DW_EH_PE_indirect for -fno-pic code (the behavior hasn't changed
since the initial port in 2012), let's follow suit by simplifying the code.
(
For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's
DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame
offset > 2GiB. This is unneeded for small code model since "Max text segment
size < 2GiB" but making -fno-pic -mcmodel={tiny,small} different seems
unnecessary: the scenarios that uses both -fno-pic and C++ exceptions have been
increasingly rare now, so there is little advantage optimizing for the little
size saving with code complexity.
)

---

Two clang/test/Interpreter tests would fail without 6747fc07d1aa94e22622e278e5a02ba70675ac9b
([ORC] Use JITLink as the default linker for LLJIT on Linux/arm64.)

[MatzeB]

LGTM, thanks

[jyknight]

For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's
DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame
offset > 2GiB.

Does this actually make sense? In small/medium, these are all required to be within 2GB anyways, no?

[MaskRay]

In D143039#4097973, @jyknight wrote:

For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's
DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame
offset > 2GiB.

Does this actually make sense? In small/medium, these are all required to be within 2GB anyways, no?

This is what the existing comment intends to support: if .eh_frame resides at 0x30000000 while personality resides at 0x1000, this is valid small code model (4GiB instead of 2GiB!)

aarch64 small code model supports 4GiB max combined code and data.

[peter.smith]

The Code Models https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst#7code-models do clarify that the text segment includes ro-data explicitly for the benefit of signed 32-bit offsets, however I don't think that this should change the decision here to use sdata8 for AArch64 targets. So no objections from me.

[MaskRay]

In D143039#4102919, @peter.smith wrote:

The Code Models https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst#7code-models do clarify that the text segment includes ro-data explicitly for the benefit of signed 32-bit offsets, however I don't think that this should change the decision here to use sdata8 for AArch64 targets. So no objections from me.

Thanks. Perhaps a better interpretation is that it is unnecessary to make -fno-pic -mcmodel={tiny,small} different. The scenarios that uses both -fno-pic and C++ exceptions have been increasingly rare now, so there is not many advantage optimizing for the little size saving here.

[chapuni]

Excuse me, I have reverted this.
See also, https://lab.llvm.org/buildbot/#/builders/183/builds/10611

[lhames]

JIT session error: Symbols not found: [ DW.ref.__gxx_personality_v0 ]

If I hand-compile source for the failing simple-execution.cpp testcase on Darwin with clang --target=arm64-pc-linux-gnu -fno-pic -S I see new references to DW.ref.__gxx_personality_v0, but I also see a definition:

        .hidden DW.ref.__gxx_personality_v0
        .weak   DW.ref.__gxx_personality_v0
        .section        .data.DW.ref.__gxx_personality_v0,"aGw",@progbits,DW.ref.__gxx_personality_v0,comdat
        .p2align        3, 0x0
        .type   DW.ref.__gxx_personality_v0,@object
        .size   DW.ref.__gxx_personality_v0, 8
DW.ref.__gxx_personality_v0:
        .xword  __gxx_personality_v0

My best guess is that the JIT linker is dropping this. I'm just doing a Linux build now so that I can figure out what's going wrong.

[MaskRay]

In D143039#4104375, @lhames wrote:

JIT session error: Symbols not found: [ DW.ref.__gxx_personality_v0 ]

If I hand-compile source for the failing simple-execution.cpp testcase on Darwin with clang --target=arm64-pc-linux-gnu -fno-pic -S I see new references to DW.ref.__gxx_personality_v0, but I also see a definition:

        .hidden DW.ref.__gxx_personality_v0
        .weak   DW.ref.__gxx_personality_v0
        .section        .data.DW.ref.__gxx_personality_v0,"aGw",@progbits,DW.ref.__gxx_personality_v0,comdat
        .p2align        3, 0x0
        .type   DW.ref.__gxx_personality_v0,@object
        .size   DW.ref.__gxx_personality_v0, 8
DW.ref.__gxx_personality_v0:
        .xword  __gxx_personality_v0

My best guess is that the JIT linker is dropping this. I'm just doing a Linux build now so that I can figure out what's going wrong.

I suspect that 43acef48d38ec0dd391f212144d4a25095e4fc5f has incomplete support.

rg DW_EH_PE_indirect llvm/lib/ExecutionEngine has no occurrence while I think it should. libunwind/src/AddressSpace.hpp:352 describes how DW_EH_PE_indirect works.

For llvm/test/ExecutionEngine/JITLink/X86/ELF_ehframe_large_static_personality_encodings.s, I think .cfi_personality 0, __gxx_personality_v0 and .cfi_personality 156, DW.ref.__gxx_personality_v0 should be in separate tests to show that .cfi_personality 156, DW.ref.__gxx_personality_v0 is correctly handled.

[lhames]

In D143039#4104425, @MaskRay wrote:

In D143039#4104375, @lhames wrote:

My best guess is that the JIT linker is dropping this. I'm just doing a Linux build now so that I can figure out what's going wrong.

I suspect that 43acef48d38ec0dd391f212144d4a25095e4fc5f has incomplete support.

I'm not sure that the linker needs to do anything with DW_EH_PE_indirect, does it? libunwind to know to do one more level of pointer chasing, but from the linker's point it's irrelevant.

Looks like the root cause is that we're not using JITLink at all -- on Linux/aarch64 we still default to using RuntimeDyld, and that's fumbling the weak symbol somehow. I'm going to try switching LLJIT's default for Linux/aarch64 to JITLink -- it's about time we did that anyway.

[lhames]

LLJIT has been update to default to JITLink on arm64 in 6747fc07d1aa, and on my local machine the interpreter tests now pass with this patch applied.

We should probably give 6747fc07d1aa a minute to settle on the bots, but then I think you're clear to re-land this.

[Hahnfeld]

For RuntimeDyld, we would have maybe needed the equivalent of 72ea1a721e005f29c6fea4a684807a68abd93c39 also for AArch64?

[MaskRay]

In D143039#4104623, @lhames wrote:

LLJIT has been update to default to JITLink on arm64 in 6747fc07d1aa, and on my local machine the interpreter tests now pass with this patch applied.

We should probably give 6747fc07d1aa a minute to settle on the bots, but then I think you're clear to re-land this.

Thanks! I tested this patch on an Ubuntu Linux aarch64 22.04 machine and check-clang-interpreter tests now pass.
(And I see how riscv64 host (which also uses DW_EH_PE_indirect) works as well: it also uses JITLink.)

llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp

case Triple::hexagon:
     }
     break;
   case Triple::aarch64:
   case Triple::aarch64_be:
   case Triple::aarch64_32:
     // The small model guarantees static code/data size < 4GB, but not where it
     // will be in memory. Most of these could end up >2GB away so even a signed
     // pc-relative 32-bit address is insufficient, theoretically.
-    if (isPositionIndependent()) {
-      // ILP32 uses sdata4 instead of sdata8
-      if (TgtM.getTargetTriple().getEnvironment() == Triple::GNUILP32) {
-        PersonalityEncoding = dwarf::DW_EH_PE_indirect | dwarf::DW_EH_PE_pcrel |
-                              dwarf::DW_EH_PE_sdata4;
-        LSDAEncoding = dwarf::DW_EH_PE_pcrel | dwarf::DW_EH_PE_sdata4;
-        TTypeEncoding = dwarf::DW_EH_PE_indirect | dwarf::DW_EH_PE_pcrel |
-                        dwarf::DW_EH_PE_sdata4;
-      } else {
-        PersonalityEncoding = dwarf::DW_EH_PE_indirect | dwarf::DW_EH_PE_pcrel |
-                              dwarf::DW_EH_PE_sdata8;
-        LSDAEncoding = dwarf::DW_EH_PE_pcrel | dwarf::DW_EH_PE_sdata8;
-        TTypeEncoding = dwarf::DW_EH_PE_indirect | dwarf::DW_EH_PE_pcrel |
-                        dwarf::DW_EH_PE_sdata8;
-      }
-    } else {
-      PersonalityEncoding = dwarf::DW_EH_PE_absptr;
-      LSDAEncoding = dwarf::DW_EH_PE_absptr;
-      TTypeEncoding = dwarf::DW_EH_PE_absptr;
-    }
+    //
+    // Use DW_EH_PE_indirect even for -fno-pic to avoid copy relocations.
+    LSDAEncoding = dwarf::DW_EH_PE_pcrel |
+                   (TgtM.getTargetTriple().getEnvironment() == Triple::GNUILP32
+                        ? dwarf::DW_EH_PE_sdata4
+                        : dwarf::DW_EH_PE_sdata8);
+    PersonalityEncoding = LSDAEncoding | dwarf::DW_EH_PE_indirect;
+    TTypeEncoding = LSDAEncoding | dwarf::DW_EH_PE_indirect;
     break;
   case Triple::lanai:
     LSDAEncoding = dwarf::DW_EH_PE_absptr;
     PersonalityEncoding = dwarf::DW_EH_PE_absptr;
     TTypeEncoding = dwarf::DW_EH_PE_absptr;
     break;
   case Triple::mips:
   case Triple::mipsel:

llvm/test/CodeGen/AArch64/arm64-big-endian-eh.ll

define linkonce_odr hidden void @__clang_call_terminate(ptr) #1 {
   unreachable
 }
 
 declare void @_ZSt9terminatev()
 
 ; CHECK-LABEL: Contents of section .eh_frame:
 ; CHECK-NEXT: {{^ 0000}}
 ; CHECK-NEXT: {{^ 0010}}
-; CHECK-NEXT: 0000 0000001c
+; CHECK-NEXT: 0020 0000000c 00440e10 9e040000 0000001c .....D..........
+; CHECK-NEXT: 0030 00000000 017a504c 5200017c 1e0b9c00 .....zPLR..|....
 

llvm/test/CodeGen/AArch64/pic-eh-stubs.ll

+; RUN: llc -mtriple=aarch64-none-linux-gnu -relocation-model=static -simplifycfg-require-and-preserve-domtree=1 -o - %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-none-linux-gnu -relocation-model=pic -simplifycfg-require-and-preserve-domtree=1 -o - %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64_be-none-linux-gnu -relocation-model=pic -simplifycfg-require-and-preserve-domtree=1 -o - %s | FileCheck %s
 
 ; Make sure exception-handling PIC code can be linked correctly. An alternative
 ; to the sequence described below would have .gcc_except_table itself writable
 ; and not use the indirection, but this isn't what LLVM does right now.
 
   ; There should be a read-only .gcc_except_table section...

llvm/test/DebugInfo/AArch64/eh_frame_personality.ll

 
 clean:
   %tst = landingpad { ptr, i32 } cleanup
   ret i64 42
 }
 
 ; CHECK: Contents of section .eh_frame:
 ; CHECK: 0000 1c000000 00000000 017a504c 5200017c  .........zPLR..|
-; CHECK: 0010 1e0b0000 00000000 00000000 1b0c1f00  ................
+; CHECK: 0010 1e0b9c00 00000000 0000001c 1b0c1f00 ................
 
 ; Don't really care about the rest:
 
 ; 0020 1c000000 24000000 00000000 24000000  ....$.......$...
 ; 0030 08000000 00000000 00440c1f 10449e02  .........D...D..
 
 ; The key test here is that the personality routine is sanely encoded (under the
 ; small memory model it must be an 8-byte value for full generality: code+data <

llvm/test/Transforms/CodeGenPrepare/AArch64/large-offset-gep.ll

 
 declare ptr @foo()
 declare void @foo2()
 
 define void @test4(i32 %n) uwtable personality ptr @__FrameHandler {
 ; CHECK-LABEL: test4:
 ; CHECK:       .Lfunc_begin0:
 ; CHECK-NEXT:    .cfi_startproc
-; CHECK-NEXT:    .cfi_personality 0, __FrameHandler
-; CHECK-NEXT:    .cfi_lsda 0, .Lexception0
+; CHECK-NEXT:    .cfi_personality 156, DW.ref.__FrameHandler
+; CHECK-NEXT:    .cfi_lsda 28, .Lexception0
 ; CHECK-NEXT:  // %bb.0: // %entry
 ; CHECK-NEXT:    stp x30, x21, [sp, #-32]! // 16-byte Folded Spill
 ; CHECK-NEXT:    .cfi_def_cfa_offset 32
 ; CHECK-NEXT:    stp x20, x19, [sp, #16] // 16-byte Folded Spill
 ; CHECK-NEXT:    .cfi_offset w19, -8
 ; CHECK-NEXT:    .cfi_offset w20, -16
 ; CHECK-NEXT:    .cfi_offset w21, -24
 ; CHECK-NEXT:    .cfi_offset w30, -32