[X86][MC] Support R_X86_64_CODE_4_GOTPC32_TLSDESC #116908

fzou1 · 2024-11-20T03:07:41Z

For

lea name@tlsdesc(%rip), %reg

add

R_X86_64_CODE_4_GOTPC32_TLSDESC = 45

if the instruction starts at 4 bytes before the relocation offset. This should be used if reg is one of the additional general-purpose registers, r16-r31, in Intel APX. It is similar to R_X86_64_GOTPC32_TLSDESC and linker optimization must take the different instruction encoding into account.

Linker can convert the instructions with R_X86_64_CODE_4_GOTPC32_TLSDESC to

mov $name@tpoff, %reg

if the first byte of the instruction at the relocation offset - 4 is 0xd5 (namely, encoded w/REX2 prefix) when possible.

Binutils patch: bminor/binutils-gdb@a533c8d
Binutils mailthread: https://sourceware.org/pipermail/binutils/2023-December/131463.html
ABI discussion: https://groups.google.com/g/x86-64-abi/c/ACwD-UQXVDs/m/vrgTenKyFwAJ
Blog: https://kanrobert.github.io/rfc/All-about-APX-relocation

llvmbot · 2024-11-20T03:08:15Z

@llvm/pr-subscribers-mc
@llvm/pr-subscribers-backend-x86

@llvm/pr-subscribers-llvm-binary-utilities

Author: Feng Zou (fzou1)

Changes

For

lea name@tlsdesc(%rip), %reg

add

R_X86_64_CODE_4_GOTPC32_TLSDESC = 45

if the instruction starts at 4 bytes before the relocation offset. This should be used if reg is one of the additional general-purpose registers, r16-r31, in Intel APX. It is similar to R_X86_64_GOTPC32_TLSDESC and linker optimization must take the different instruction encoding into account.

Linker can convert the instructions with R_X86_64_CODE_4_GOTPC32_TLSDESC to

mov $name@tpoff, %reg

if the first byte of the instruction at the relocation offset - 4 is 0xd5 (namely, encoded w/REX2 prefix) when possible.

Binutils patch: bminor/binutils-gdb@a533c8d
Binutils mailthread: https://sourceware.org/pipermail/binutils/2023-December/131463.html
ABI discussion: https://groups.google.com/g/x86-64-abi/c/ACwD-UQXVDs/m/vrgTenKyFwAJ
Blog: https://kanrobert.github.io/rfc/All-about-APX-relocation

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

4 Files Affected:

(modified) llvm/include/llvm/BinaryFormat/ELFRelocs/x86_64.def (+1)
(modified) llvm/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp (+2)
(modified) llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp (+1)
(modified) llvm/test/MC/X86/tlsdesc-64.s (+12)

diff --git a/llvm/include/llvm/BinaryFormat/ELFRelocs/x86_64.def b/llvm/include/llvm/BinaryFormat/ELFRelocs/x86_64.def
index 161b1969abfeb4..1008263b3213ec 100644
--- a/llvm/include/llvm/BinaryFormat/ELFRelocs/x86_64.def
+++ b/llvm/include/llvm/BinaryFormat/ELFRelocs/x86_64.def
@@ -44,3 +44,4 @@ ELF_RELOC(R_X86_64_IRELATIVE,   37)
 ELF_RELOC(R_X86_64_GOTPCRELX,   41)
 ELF_RELOC(R_X86_64_REX_GOTPCRELX,    42)
 ELF_RELOC(R_X86_64_REX2_GOTPCRELX,    43)
+ELF_RELOC(R_X86_64_CODE_4_GOTPC32_TLSDESC,    45)
\ No newline at end of file
diff --git a/llvm/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp b/llvm/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp
index 90222278d1ad6f..f0a7cc7c263e55 100644
--- a/llvm/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp
+++ b/llvm/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp
@@ -191,6 +191,8 @@ static unsigned getRelocType64(MCContext &Ctx, SMLoc Loc,
   case MCSymbolRefExpr::VK_TLSCALL:
     return ELF::R_X86_64_TLSDESC_CALL;
   case MCSymbolRefExpr::VK_TLSDESC:
+    if ((unsigned)Kind == X86::reloc_riprel_4byte_relax_rex2)
+      return ELF::R_X86_64_CODE_4_GOTPC32_TLSDESC;
     return ELF::R_X86_64_GOTPC32_TLSDESC;
   case MCSymbolRefExpr::VK_TLSGD:
     checkIs32(Ctx, Loc, Type);
diff --git a/llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp b/llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
index 206436191c2584..510fc9fc417f2f 100644
--- a/llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
+++ b/llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
@@ -666,6 +666,7 @@ void X86MCCodeEmitter::emitMemModRMByte(
       case X86::SBB64rm:
       case X86::SUB64rm:
       case X86::XOR64rm:
+      case X86::LEA64r:
         return Kind == REX2  ? X86::reloc_riprel_4byte_relax_rex2
                : Kind == REX ? X86::reloc_riprel_4byte_relax_rex
                              : X86::reloc_riprel_4byte_relax;
diff --git a/llvm/test/MC/X86/tlsdesc-64.s b/llvm/test/MC/X86/tlsdesc-64.s
index ebe1710c3e869b..93e0f2bda0691d 100644
--- a/llvm/test/MC/X86/tlsdesc-64.s
+++ b/llvm/test/MC/X86/tlsdesc-64.s
@@ -17,3 +17,15 @@
 leaq a@tlsdesc(%rip), %rax
 call *a@tlscall(%rax)
 addq %fs:0, %rax
+
+# PRINT:      leaq a@tlsdesc(%rip), %r16
+# PRINT-NEXT: callq *a@tlscall(%r16)
+
+# CHECK:      12: leaq (%rip), %r16  # 0x1a <{{.*}}>
+# CHECK-NEXT:   0000000000000016: R_X86_64_CODE_4_GOTPC32_TLSDESC a-0x4
+# CHECK-NEXT: 1a: callq *(%r16)
+# CHECK-NEXT:   000000000000001a: R_X86_64_TLSDESC_CALL a
+
+leaq a@tlsdesc(%rip), %r16
+call *a@tlscall(%r16)
+addq %fs:0, %r16
\ No newline at end of file

For lea name@tlsdesc(%rip), %reg add R_X86_64_CODE_4_GOTPC32_TLSDESC = 45 in llvm#116908. Linker can treat R_X86_64_CODE_4_GOTPC32_TLSDESC as R_X86_64_GOTPC32_TLSDESC or convert the instruction above to mov $name@tpoff, %reg if the first byte of the instruction at the relocation offset - 4 is 0xd5 (namely, encoded w/REX2 prefix) when possible. Binutils patch: bminor/binutils-gdb@a533c8d Binutils mailthread: https://sourceware.org/pipermail/binutils/2023-December/131463.html ABI discussion: https://groups.google.com/g/x86-64-abi/c/ACwD-UQXVDs/m/vrgTenKyFwAJ Blog: https://kanrobert.github.io/rfc/All-about-APX-relocation

KanRobert · 2024-11-20T12:31:07Z

llvm/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp

+    if ((unsigned)Kind == X86::reloc_riprel_4byte_relax_rex2)
+      return ELF::R_X86_64_CODE_4_GOTPC32_TLSDESC;
    return ELF::R_X86_64_GOTPC32_TLSDESC;


Use condition operator?

Okay. I'll update.

KanRobert · 2024-11-20T12:34:12Z

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

@@ -44,3 +44,4 @@ ELF_RELOC(R_X86_64_IRELATIVE,   37)
 ELF_RELOC(R_X86_64_GOTPCRELX,   41)
 ELF_RELOC(R_X86_64_REX_GOTPCRELX,    42)
 ELF_RELOC(R_X86_64_REX2_GOTPCRELX,    43)


Maybe merge #116737 first and rebase? So that it does not look strange.

Okay for me. Please help merge that PR. Thanks.

KanRobert · 2024-11-20T12:35:48Z

llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp

@@ -666,6 +666,7 @@ void X86MCCodeEmitter::emitMemModRMByte(
      case X86::SBB64rm:
      case X86::SUB64rm:
      case X86::XOR64rm:
+      case X86::LEA64r:


We don't need LEA64r before REX2?

Sorry. I don't understand. We need to check LEA64r with REX2 prefix and add R_X86_64_CODE_4_GOTPC32_TLSDESC relocation for it.

My question is: Why we don't need to check LEA64r when REX prefix was added? Is LEA64r special to REX2?

It's not special to REX2. Here we need to distinguish REX2 prefix and others and set corresponding relocation type (R_X86_64_CODE_4_GOTPC32_TLSDESC) if it's REX2 prefix. For REX prefix, we didn't have to distinguish it and others in the past.

MaskRay

Code/test looks good to me

For lea name@tlsdesc(%rip), %reg add R_X86_64_CODE_4_GOTPC32_TLSDESC = 45 if the instruction starts at 4 bytes before the relocation offset. This should be used if reg is one of the additional general-purpose registers, r16-r31, in Intel APX. It is similar to R_X86_64_GOTPC32_TLSDESC and linker optimization must take the different instruction encoding into account. Linker can convert the instructions with R_X86_64_CODE_4_GOTPC32_TLSDESC to mov $name@tpoff, %reg if the first byte of the instruction at the relocation offset - 4 is 0xd5 (namely, encoded w/REX2 prefix) when possible. Binutils patch: bminor/binutils-gdb@a533c8d Binutils mailthread: https://sourceware.org/pipermail/binutils/2023-December/131463.html ABI discussion: https://groups.google.com/g/x86-64-abi/c/ACwD-UQXVDs/m/vrgTenKyFwAJ Blog: https://kanrobert.github.io/rfc/All-about-APX-relocation

KanRobert · 2024-11-21T12:29:27Z

llvm/test/MC/X86/tlsdesc-64.s

+# CHECK:      12: leaq (%rip), %r16  # 0x1a <{{.*}}>
+# CHECK-NEXT:   0000000000000016: R_X86_64_CODE_4_GOTPC32_TLSDESC a-0x4
+# CHECK-NEXT: 1a: callq *(%r16)
+# CHECK-NEXT:   000000000000001a: R_X86_64_TLSDESC_CALL a


Is R_X86_64_TLSDESC_CALL expected? Or we need to check R_X86_64_CODE_4_TLSDESC_CALL?

Yes. R_X86_64_TLSDESC_CALL is expected. There is no R_X86_64_CODE_4_TLSDESC_CALL type. As I understand, we don't need to rewrite/change the instruction so we don't need to know how many bytes the instruction starts before relocation offset.

KanRobert

LGTM

For lea name@tlsdesc(%rip), %reg add R_X86_64_CODE_4_GOTPC32_TLSDESC = 45 in llvm#116908. Linker can treat R_X86_64_CODE_4_GOTPC32_TLSDESC as R_X86_64_GOTPC32_TLSDESC or convert the instruction above to mov $name@tpoff, %reg if the first byte of the instruction at the relocation offset - 4 is 0xd5 (namely, encoded w/REX2 prefix) when possible. Binutils patch: bminor/binutils-gdb@a533c8d Binutils mailthread: https://sourceware.org/pipermail/binutils/2023-December/131463.html ABI discussion: https://groups.google.com/g/x86-64-abi/c/ACwD-UQXVDs/m/vrgTenKyFwAJ Blog: https://kanrobert.github.io/rfc/All-about-APX-relocation

…16909) For lea name@tlsdesc(%rip), %reg add R_X86_64_CODE_4_GOTPC32_TLSDESC = 45 in #116908. Linker can treat R_X86_64_CODE_4_GOTPC32_TLSDESC as R_X86_64_GOTPC32_TLSDESC or convert the instruction above to mov $name@tpoff, %reg if the first byte of the instruction at the relocation offset - 4 is 0xd5 (namely, encoded w/REX2 prefix) when possible. Binutils patch: bminor/binutils-gdb@a533c8d Binutils mailthread: https://sourceware.org/pipermail/binutils/2023-December/131463.html ABI discussion: https://groups.google.com/g/x86-64-abi/c/ACwD-UQXVDs/m/vrgTenKyFwAJ Blog: https://kanrobert.github.io/rfc/All-about-APX-relocation

llvmbot added backend:X86 mc Machine (object) code llvm:binary-utilities labels Nov 20, 2024

fzou1 mentioned this pull request Nov 20, 2024

[X86][LLD] Handle R_X86_64_CODE_4_GOTPC32_TLSDESC relocation type #116909

Merged

RKSimon requested a review from KanRobert November 20, 2024 10:58

KanRobert requested a review from MaskRay November 20, 2024 12:27

KanRobert reviewed Nov 20, 2024

View reviewed changes

MaskRay reviewed Nov 20, 2024

View reviewed changes

fzou1 added 2 commits November 21, 2024 18:37

Added trailing '\n'.

a45ba4f

fzou1 force-pushed the mc-code-4-tlsdesc branch from 10360a6 to a45ba4f Compare November 21, 2024 10:40

Address comments.

b2adcd5

KanRobert reviewed Nov 21, 2024

View reviewed changes

KanRobert approved these changes Nov 22, 2024

View reviewed changes

KanRobert merged commit 8223982 into llvm:main Nov 22, 2024
8 checks passed

fzou1 deleted the mc-code-4-tlsdesc branch November 22, 2024 01:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[X86][MC] Support R_X86_64_CODE_4_GOTPC32_TLSDESC #116908

[X86][MC] Support R_X86_64_CODE_4_GOTPC32_TLSDESC #116908

Uh oh!

fzou1 commented Nov 20, 2024

Uh oh!

llvmbot commented Nov 20, 2024 •

edited

Loading

Uh oh!

KanRobert Nov 20, 2024

Uh oh!

fzou1 Nov 20, 2024

Uh oh!

KanRobert Nov 20, 2024

Uh oh!

fzou1 Nov 20, 2024 •

edited

Loading

Uh oh!

KanRobert Nov 20, 2024

Uh oh!

fzou1 Nov 20, 2024

Uh oh!

KanRobert Nov 20, 2024

Uh oh!

fzou1 Nov 21, 2024

Uh oh!

KanRobert Nov 21, 2024

Uh oh!

MaskRay left a comment

Uh oh!

KanRobert Nov 21, 2024

Uh oh!

fzou1 Nov 22, 2024

Uh oh!

KanRobert left a comment

Uh oh!

Uh oh!

Uh oh!

[X86][MC] Support R_X86_64_CODE_4_GOTPC32_TLSDESC #116908

[X86][MC] Support R_X86_64_CODE_4_GOTPC32_TLSDESC #116908

Uh oh!

Conversation

fzou1 commented Nov 20, 2024

Uh oh!

llvmbot commented Nov 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fzou1 Nov 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MaskRay left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KanRobert left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

llvmbot commented Nov 20, 2024 •

edited

Loading

fzou1 Nov 20, 2024 •

edited

Loading