Skip to content

Target: Stop assigning RELRO sections to .ldata.rel.ro. #137742

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

pcc
Copy link
Contributor

@pcc pcc commented Apr 29, 2025

Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
sections; that would require the linker to emit more than one
PT_GNU_RELRO because large sections are discontiguous by design,
and most ELF dynamic loaders do not support that (bionic appears to
support it but glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With
current linkers these sections will end up in .ldata which results
in silently disabling RELRO. Therefore, disable SHF_X86_64_LARGE for
RELRO sections. If this ever gets supported by downstream components
in the future we could add an opt-in flag for moving these sections
to .ldata.rel.ro which would trigger the creation of a second
PT_GNU_RELRO.

Created using spr 1.3.6-beta.1
@pcc pcc requested review from aeubanks and MaskRay April 29, 2025 00:53
@llvmbot
Copy link
Member

llvmbot commented Apr 29, 2025

@llvm/pr-subscribers-backend-x86

Author: Peter Collingbourne (pcc)

Changes

Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
sections; that would require the linker to emit more than one
PT_GNU_RELRO because large sections are discontiguous by design,
and most ELF dynamic loaders do not support that (bionic appears to
support it but glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With
current linkers these sections will end up in .ldata which results
in silently disabling RELRO. Therefore, disable SHF_X86_64_LARGE for
RELRO sections. If this ever gets supported by downstream components
in the future we could add an opt-in flag for moving these sections
to .ldata.rel.ro which would trigger the creation of a second
PT_GNU_RELRO.


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

3 Files Affected:

  • (modified) llvm/lib/Target/TargetMachine.cpp (+13)
  • (modified) llvm/test/CodeGen/X86/code-model-elf-sections.ll (+2-2)
  • (modified) llvm/test/CodeGen/X86/code-model-elf.ll (+19-21)
diff --git a/llvm/lib/Target/TargetMachine.cpp b/llvm/lib/Target/TargetMachine.cpp
index 439e735e9d66e..69b6e26e602f6 100644
--- a/llvm/lib/Target/TargetMachine.cpp
+++ b/llvm/lib/Target/TargetMachine.cpp
@@ -119,6 +119,19 @@ bool TargetMachine::isLargeGlobalValue(const GlobalValue *GVal) const {
                                 GV->getName().starts_with("__start_") ||
                                 GV->getName().starts_with("__stop_")))
       return true;
+    // Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
+    // sections; that would require the linker to emit more than one
+    // PT_GNU_RELRO because large sections are discontiguous by design, and most
+    // ELF dynamic loaders do not support that (bionic appears to support it but
+    // glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With current linkers
+    // these sections will end up in .ldata which results in silently disabling
+    // RELRO. If this ever gets supported by downstream components in the future
+    // we could add an opt-in flag for moving these sections to .ldata.rel.ro
+    // which would trigger the creation of a second PT_GNU_RELRO.
+    if (!GV->isDeclarationForLinker() &&
+        TargetLoweringObjectFile::getKindForGlobal(GV, *this)
+            .isReadOnlyWithRel())
+      return false;
     const DataLayout &DL = GV->getDataLayout();
     uint64_t Size = DL.getTypeAllocSize(GV->getValueType());
     return Size == 0 || Size > LargeDataThreshold;
diff --git a/llvm/test/CodeGen/X86/code-model-elf-sections.ll b/llvm/test/CodeGen/X86/code-model-elf-sections.ll
index fc5dac89a6b3d..f7a7ebb705ea6 100644
--- a/llvm/test/CodeGen/X86/code-model-elf-sections.ll
+++ b/llvm/test/CodeGen/X86/code-model-elf-sections.ll
@@ -66,7 +66,7 @@
 ; LARGE: .lbss {{.*}} WAl {{.*}}
 ; LARGE: .rodata {{.*}} A {{.*}}
 ; LARGE: .lrodata {{.*}} Al {{.*}}
-; LARGE: .ldata.rel.ro {{.*}} WAl {{.*}}
+; LARGE: .data.rel.ro {{.*}} WA {{.*}}
 ; LARGE: .tbss {{.*}} WAT {{.*}}
 ; LARGE: .tdata {{.*}} WAT {{.*}}
 
@@ -84,7 +84,7 @@
 ; LARGE-DS: .lbss.bss {{.*}} WAl {{.*}}
 ; LARGE-DS: .rodata {{.*}} A {{.*}}
 ; LARGE-DS: .lrodata.rodata {{.*}} Al {{.*}}
-; LARGE-DS: .ldata.rel.ro.relro {{.*}} WAl {{.*}}
+; LARGE-DS: .data.rel.ro.relro {{.*}} WA {{.*}}
 ; LARGE-DS: .tbss.tbss {{.*}} WAT {{.*}}
 ; LARGE-DS: .tdata.tdata {{.*}} WAT {{.*}}
 
diff --git a/llvm/test/CodeGen/X86/code-model-elf.ll b/llvm/test/CodeGen/X86/code-model-elf.ll
index f60f75bc26911..aa2cc3a4981a2 100644
--- a/llvm/test/CodeGen/X86/code-model-elf.ll
+++ b/llvm/test/CodeGen/X86/code-model-elf.ll
@@ -50,7 +50,7 @@ target triple = "x86_64--linux"
 
 @global_data = dso_local global [10 x i32] [i32 1, i32 2, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0], align 16
 @static_data = internal global [10 x i32] zeroinitializer, align 16
-@static_data_alias = internal constant ptr getelementptr inbounds ([10 x i32], ptr @static_data, i64 0, i64 2), align 8
+@static_data_relro = internal constant ptr getelementptr inbounds ([10 x i32], ptr @static_data, i64 0, i64 2), align 8
 @extern_data = external global [10 x i32], align 16
 @thread_data = external thread_local global i32, align 4
 @unknown_size_data = dso_local global [0 x i32] zeroinitializer, align 16
@@ -117,59 +117,57 @@ define dso_local ptr @lea_static_data() #0 {
   ret ptr @static_data
 }
 
-define dso_local ptr @lea_static_data_alias() #0 {
-; SMALL-STATIC-LABEL: lea_static_data_alias:
+define dso_local ptr @lea_static_data_relro() #0 {
+; SMALL-STATIC-LABEL: lea_static_data_relro:
 ; SMALL-STATIC:       # %bb.0:
-; SMALL-STATIC-NEXT:    movl $static_data_alias, %eax
+; SMALL-STATIC-NEXT:    movl $static_data_relro, %eax
 ; SMALL-STATIC-NEXT:    retq
 ;
-; MEDIUM-STATIC-LABEL: lea_static_data_alias:
+; MEDIUM-STATIC-LABEL: lea_static_data_relro:
 ; MEDIUM-STATIC:       # %bb.0:
-; MEDIUM-STATIC-NEXT:    movabsq $static_data_alias, %rax
+; MEDIUM-STATIC-NEXT:    movabsq $static_data_relro, %rax
 ; MEDIUM-STATIC-NEXT:    retq
 ;
-; LARGE-STATIC-LABEL: lea_static_data_alias:
+; LARGE-STATIC-LABEL: lea_static_data_relro:
 ; LARGE-STATIC:       # %bb.0:
-; LARGE-STATIC-NEXT:    movabsq $static_data_alias, %rax
+; LARGE-STATIC-NEXT:    movabsq $static_data_relro, %rax
 ; LARGE-STATIC-NEXT:    retq
 ;
-; SMALL-PIC-LABEL: lea_static_data_alias:
+; SMALL-PIC-LABEL: lea_static_data_relro:
 ; SMALL-PIC:       # %bb.0:
-; SMALL-PIC-NEXT:    leaq static_data_alias(%rip), %rax
+; SMALL-PIC-NEXT:    leaq static_data_relro(%rip), %rax
 ; SMALL-PIC-NEXT:    retq
 ;
-; MEDIUM-SMALL-DATA-PIC-LABEL: lea_static_data_alias:
+; MEDIUM-SMALL-DATA-PIC-LABEL: lea_static_data_relro:
 ; MEDIUM-SMALL-DATA-PIC:       # %bb.0:
-; MEDIUM-SMALL-DATA-PIC-NEXT:    leaq static_data_alias(%rip), %rax
+; MEDIUM-SMALL-DATA-PIC-NEXT:    leaq static_data_relro(%rip), %rax
 ; MEDIUM-SMALL-DATA-PIC-NEXT:    retq
 ;
-; MEDIUM-PIC-LABEL: lea_static_data_alias:
+; MEDIUM-PIC-LABEL: lea_static_data_relro:
 ; MEDIUM-PIC:       # %bb.0:
-; MEDIUM-PIC-NEXT:    leaq _GLOBAL_OFFSET_TABLE_(%rip), %rcx
-; MEDIUM-PIC-NEXT:    movabsq $static_data_alias@GOTOFF, %rax
-; MEDIUM-PIC-NEXT:    addq %rcx, %rax
+; MEDIUM-PIC-NEXT:    leaq static_data_relro(%rip), %rax
 ; MEDIUM-PIC-NEXT:    retq
 ;
-; LARGE-PIC-LABEL: lea_static_data_alias:
+; LARGE-PIC-LABEL: lea_static_data_relro:
 ; LARGE-PIC:       # %bb.0:
 ; LARGE-PIC-NEXT:  .L1$pb:
 ; LARGE-PIC-NEXT:    leaq .L1$pb(%rip), %rax
 ; LARGE-PIC-NEXT:    movabsq $_GLOBAL_OFFSET_TABLE_-.L1$pb, %rcx
 ; LARGE-PIC-NEXT:    addq %rax, %rcx
-; LARGE-PIC-NEXT:    movabsq $static_data_alias@GOTOFF, %rax
+; LARGE-PIC-NEXT:    movabsq $static_data_relro@GOTOFF, %rax
 ; LARGE-PIC-NEXT:    addq %rcx, %rax
 ; LARGE-PIC-NEXT:    retq
 ;
-; LARGE-SMALL-DATA-PIC-LABEL: lea_static_data_alias:
+; LARGE-SMALL-DATA-PIC-LABEL: lea_static_data_relro:
 ; LARGE-SMALL-DATA-PIC:       # %bb.0:
 ; LARGE-SMALL-DATA-PIC-NEXT:  .L1$pb:
 ; LARGE-SMALL-DATA-PIC-NEXT:    leaq .L1$pb(%rip), %rax
 ; LARGE-SMALL-DATA-PIC-NEXT:    movabsq $_GLOBAL_OFFSET_TABLE_-.L1$pb, %rcx
 ; LARGE-SMALL-DATA-PIC-NEXT:    addq %rax, %rcx
-; LARGE-SMALL-DATA-PIC-NEXT:    movabsq $static_data_alias@GOTOFF, %rax
+; LARGE-SMALL-DATA-PIC-NEXT:    movabsq $static_data_relro@GOTOFF, %rax
 ; LARGE-SMALL-DATA-PIC-NEXT:    addq %rcx, %rax
 ; LARGE-SMALL-DATA-PIC-NEXT:    retq
-  ret ptr @static_data_alias
+  ret ptr @static_data_relro
 }
 
 define dso_local ptr @lea_global_data() #0 {

@pcc pcc merged commit c88b537 into main Apr 29, 2025
11 of 13 checks passed
@pcc pcc deleted the users/pcc/spr/target-stop-assigning-relro-sections-to-ldatarelro branch April 29, 2025 19:40
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
sections; that would require the linker to emit more than one
PT_GNU_RELRO because large sections are discontiguous by design,
and most ELF dynamic loaders do not support that (bionic appears to
support it but glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With
current linkers these sections will end up in .ldata which results
in silently disabling RELRO. Therefore, disable SHF_X86_64_LARGE for
RELRO sections. If this ever gets supported by downstream components
in the future we could add an opt-in flag for moving these sections
to .ldata.rel.ro which would trigger the creation of a second
PT_GNU_RELRO.

Reviewers: MaskRay, aeubanks

Reviewed By: aeubanks

Pull Request: llvm#137742
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
sections; that would require the linker to emit more than one
PT_GNU_RELRO because large sections are discontiguous by design,
and most ELF dynamic loaders do not support that (bionic appears to
support it but glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With
current linkers these sections will end up in .ldata which results
in silently disabling RELRO. Therefore, disable SHF_X86_64_LARGE for
RELRO sections. If this ever gets supported by downstream components
in the future we could add an opt-in flag for moving these sections
to .ldata.rel.ro which would trigger the creation of a second
PT_GNU_RELRO.

Reviewers: MaskRay, aeubanks

Reviewed By: aeubanks

Pull Request: llvm#137742
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
sections; that would require the linker to emit more than one
PT_GNU_RELRO because large sections are discontiguous by design,
and most ELF dynamic loaders do not support that (bionic appears to
support it but glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With
current linkers these sections will end up in .ldata which results
in silently disabling RELRO. Therefore, disable SHF_X86_64_LARGE for
RELRO sections. If this ever gets supported by downstream components
in the future we could add an opt-in flag for moving these sections
to .ldata.rel.ro which would trigger the creation of a second
PT_GNU_RELRO.

Reviewers: MaskRay, aeubanks

Reviewed By: aeubanks

Pull Request: llvm#137742
llvm-sync bot pushed a commit to arm/arm-toolchain that referenced this pull request May 6, 2025
Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
sections; that would require the linker to emit more than one
PT_GNU_RELRO because large sections are discontiguous by design,
and most ELF dynamic loaders do not support that (bionic appears to
support it but glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With
current linkers these sections will end up in .ldata which results
in silently disabling RELRO. Therefore, disable SHF_X86_64_LARGE for
RELRO sections. If this ever gets supported by downstream components
in the future we could add an opt-in flag for moving these sections
to .ldata.rel.ro which would trigger the creation of a second
PT_GNU_RELRO.

Reviewers: MaskRay, aeubanks

Reviewed By: aeubanks

Pull Request: llvm/llvm-project#137742
GeorgeARM pushed a commit to GeorgeARM/llvm-project that referenced this pull request May 7, 2025
Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
sections; that would require the linker to emit more than one
PT_GNU_RELRO because large sections are discontiguous by design,
and most ELF dynamic loaders do not support that (bionic appears to
support it but glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With
current linkers these sections will end up in .ldata which results
in silently disabling RELRO. Therefore, disable SHF_X86_64_LARGE for
RELRO sections. If this ever gets supported by downstream components
in the future we could add an opt-in flag for moving these sections
to .ldata.rel.ro which would trigger the creation of a second
PT_GNU_RELRO.

Reviewers: MaskRay, aeubanks

Reviewed By: aeubanks

Pull Request: llvm#137742
Ankur-0429 pushed a commit to Ankur-0429/llvm-project that referenced this pull request May 9, 2025
Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
sections; that would require the linker to emit more than one
PT_GNU_RELRO because large sections are discontiguous by design,
and most ELF dynamic loaders do not support that (bionic appears to
support it but glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With
current linkers these sections will end up in .ldata which results
in silently disabling RELRO. Therefore, disable SHF_X86_64_LARGE for
RELRO sections. If this ever gets supported by downstream components
in the future we could add an opt-in flag for moving these sections
to .ldata.rel.ro which would trigger the creation of a second
PT_GNU_RELRO.

Reviewers: MaskRay, aeubanks

Reviewed By: aeubanks

Pull Request: llvm#137742
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants