[SSP] Accessing __stack_chk_guard when using LTO

[wolfy1961]

This is a pre-commit test of accessing the variable __stack_chk_guard when the static relocation model is imposed on a module compiled with pic enabled. It confirms issue #64999.

The intent is to update this test with the fix for the aforementioned issue.

[llvmbot]

@llvm/pr-subscribers-lto

Changes

This is a pre-commit test of accessing the variable __stack_chk_guard when the static relocation model is imposed on a module compiled with pic enabled. It confirms issue #64999.

The intent is to update this test with the fix for the aforementioned issue.

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

1 Files Affected:

• (added) llvm/test/LTO/ARM/ssp-static-reloc.ll (+40)

diff --git a/llvm/test/LTO/ARM/ssp-static-reloc.ll b/llvm/test/LTO/ARM/ssp-static-reloc.ll
new file mode 100644
index 000000000000000..ca32505996b8656
--- /dev/null
+++ b/llvm/test/LTO/ARM/ssp-static-reloc.ll
@@ -0,0 +1,40 @@
+; Confirm that we do generate one too many indirections accessing the stack guard
+; variable, when the relocation model is static.
+; This is preparation for the fix. 
+;
+; RUN: llvm-as < %s > %t.bc
+; RUN: llvm-lto -O0 -relocation-model=static -o %t.o %t.bc
+; RUN: llvm-objdump -d -r %t.o | FileCheck %s
+
+target triple = "armv4t-unknown-unknown"
+
+define arm_aapcscc i8 @foo() #0 {
+entry:
+  %arr = alloca [200 x i8], align 1
+  call void @llvm.memset.p0.i32(ptr align 1 %arr, i8 0, i32 200, i1 false)
+  %arrayidx = getelementptr inbounds [200 x i8], ptr %arr, i32 0, i8 5
+  %0 = load i8, ptr %arrayidx, align 1
+  ret i8 %0
+}
+
+; CHECK:      <foo>:
+; CHECK:      [[#%x,CURPC:]]:{{.*}} ldr r[[REG1:[0-9]+]], [pc, #0x[[#%x,OFFSET:]]]
+; CHECK-NEXT: ldr r[[REG2:[0-9]+]], [r[[REG1]]]
+; CHECK-NEXT: ldr r[[REG3:[0-9]+]], [r[[REG2]]]
+; CHECK-NEXT: str r[[REG3]],
+; CHECK:      [[#CURPC + OFFSET + 8]]:{{.*}}.word
+; CHECK-NEXT: R_ARM_ABS32 __stack_chk_guard
+
+declare void @llvm.memset.p0.i32(ptr nocapture writeonly, i8, i32, i1 immarg)
+
+define arm_aapcscc i32 @main() {
+entry:
+  %call = call arm_aapcscc i8 @foo()
+  %conv = zext i8 %call to i32
+  ret i32 %conv
+}
+
+attributes #0 = { noinline nounwind optnone sspstrong }
+
+!llvm.module.flags = !{!0}
+!0 = !{i32 8, !"PIC Level", i32 2}

[RKSimon]

is all this meta data necessary?

[wolfy1961]

We need sspstrong and PIC Level to demonstrate the problem, i.e. the guard variable is accessed like we're generating PIC code even though there is no GOT.

[RKSimon]

LGTM