x86 stack protector code references @GOTPCREL and @PLT even when built with -fno-pic or -fno-pie

[nickdesaulniers]

// -fstack-protector-strong -O2 -mstack-protector-guard-reg=gs -mstack-protector-guard-symbol=__stack_chk_guard -fno-pie
void foo (int*);

void bar (int x) {
    int y [x];
    foo(y);
}

generates

bar:                                    # @bar
        pushq   %rbp
        movq    %rsp, %rbp
        pushq   %rbx
        pushq   %rax
        movq    __stack_chk_guard@GOTPCREL(%rip), %rbx
        movq    %gs:(%rbx), %rax
        movq    %rax, -16(%rbp)
        movl    %edi, %eax
        movq    %rsp, %rdi
        leaq    15(,%rax,4), %rax
        andq    $-16, %rax
        subq    %rax, %rdi
        movq    %rdi, %rsp
        callq   foo
        movq    %gs:(%rbx), %rax
        cmpq    -16(%rbp), %rax
        jne     .LBB0_2
        leaq    -8(%rbp), %rsp
        popq    %rbx
        popq    %rbp
        retq
.LBB0_2:
        callq   __stack_chk_fail@PLT

Those @GOTPCREL and @PLT are unexpected I think. This is affecting the Linux kernel's ability to use per-cpu stack canaries. https://lore.kernel.org/lkml/7cee0c83225ffd8cf8fd0065bea9348f6db3b12a.1682673543.git.houwenlong.hwl@antgroup.com/

[llvmbot]

@llvm/issue-subscribers-backend-x86

[ardbiesheuvel]

Seeing the same - no combination of -fno-pic, -fno-pie, -fvisiblity=[hidden|protected] (on the command line or with #pragma) or -fdirect-access-external-data can coerce the compiler into referring to the symbol directly.

[nickdesaulniers]

Duplicate of #60116.