[LTO][PIC][ARM][SSP] extra indirection accessing __stack_chk_guard

[wolfy1961]

After commit e018cbf7208b we're seeing segfaults when accessing __stack_chk_guard when using LTO. I'm attaching a small test case (3 source files and small build script) that shows the problem). When compiling with -flto -fPIC and linking without any additional flags, we're seeing the following code in the function foo:

201dc: e59f006c      ldr     r0, [pc, #0x6c]         @ 0x20250 <foo+0x80>
201e0: e5900000      ldr     r0, [r0]
201e4: e5900000      ldr     r0, [r0]
201e8: e50b000c      str     r0, [r11, #-0xc]
...
20250: 54 02 03 00   .word   0x00030254

And from the linker map file:

30254    30254        4     1                 __stack_chk_guard

So we're seeing an extra indirection, causing the segfaults.

If we're adding -pie to the link line, things work fine. We see:

   10280: e59f0074      ldr     r0, [pc, #0x74]         @ 0x102fc <foo+0x88>
   10284: e08f0000      add     r0, pc, r0
   10288: e5900000      ldr     r0, [r0]
   1028c: e5900000      ldr     r0, [r0]
    ...
   102fc: e4 00 01 00   .word   0x000100e4

with the GOT present in the executable.

Note that the the test case is not meant to execute anywhere. A rudimentary module (rt.c) supplies the missing definitions.
stack_check.zip

[MaskRay]

Sorry for my late response.

So we're seeing an extra indirection, causing the segfaults.

Reproduced. Compiling with -fPIC 1.c and linking with the default -no-pie gives:

foo:
        .fnstart
@ %bb.0:                                @ %entry
        push    {r4, r10, r11, lr}
        add     r11, sp, #8
        sub     sp, sp, #208
        ldr     r0, .LCPI2_1     # load the address of `__stack_chk_guard`.
        ldr     r0, [r0]         # load the value of `__stack_chk_guard`
        ldr     r0, [r0]         # wrong
...
.LCPI0_1:
        .long   __stack_chk_guard

I believe this is an AArch32 codegen issue. It doesn't handle dso_preemptable variables correctly when the TargetMachine uses the static relocation model.

#65512 just papers over the issue and will not work if we emit direct-access-external-data=1 unconditionally for -fPIC code.

For x86-64 and AArch64, GOT-generating relocations are correctly used when accessing __stack_chk_guard.

[klzgrad]

The fix in #70014 seems to be incomplete.

After adding -mthumb to 1.c, the GOT PIC sequence is lost:

clang-18 -target arm-unknown-unknown -flto -fPIC -fstack-protector-strong -mthumb -c 1.c
llc-18 1.o

foo:
        .fnstart
@ %bb.0:
        push    {r4, r6, r7, lr}
        add     r7, sp, #8
        sub     sp, #208
        ldr     r0, .LCPI0_1
        ldr     r0, [r0]
        ldr     r0, [r0]
        str     r0, [sp, #204]
...
.LCPI0_1:
        .long   __stack_chk_guard

Without -mthumb:

foo:
        .fnstart
@ %bb.0:
        push    {r4, r10, r11, lr}
        add     r11, sp, #8
        sub     sp, sp, #208
        ldr     r0, .LCPI0_1
.LPC0_0:
        add     r0, pc, r0
        ldr     r0, [r0]
        ldr     r0, [r0]
        str     r0, [r11, #-12]
...
.LCPI0_1:
.Ltmp0:
        .long   __stack_chk_guard(GOT_PREL)-((.LPC0_0+8)-.Ltmp0)
.LCPI0_2:
.Ltmp1:
        .long   __stack_chk_guard(GOT_PREL)-((.LPC0_1+8)-.Ltmp1)