undefined reference to `__stack_chk_guard' when building with sandbox_defconfig

[McLaughlin Amy]

At my workplace, I ran:

make distclean
make sandbox_defconfig
make all

The result:

  LTO     u-boot
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `pci_io_read':
/home/mclauam/gitclone/u-boot/arch/sandbox/lib/pci_io.c:52:(.text+0x3d1): undefined reference to `__stack_chk_guard'
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `get_token':
/home/mclauam/gitclone/u-boot/boot/pxe_utils.c:943:(.text+0x755): undefined reference to `__stack_chk_guard'
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `parse_sliteral':
/home/mclauam/gitclone/u-boot/boot/pxe_utils.c:1010:(.text+0x898): undefined reference to `__stack_chk_guard'
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `parse_integer':
/home/mclauam/gitclone/u-boot/boot/pxe_utils.c:1030:(.text+0x91a): undefined reference to `__stack_chk_guard'
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `os_printf':
/home/mclauam/gitclone/u-boot/arch/sandbox/cpu/os.c:59:(.text+0xb3c): undefined reference to `__stack_chk_guard'
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o:/home/mclauam/gitclone/u-boot/arch/sandbox/cpu/start.c:203: more undefined references to `__stack_chk_guard' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile:1766: u-boot] Error 1

I can get past this by either:

1.) Commenting out the `KBUILD_CFLAGS += $(call cc-option,-mstack-protector-guard=global)` lines in the makefile
Or
2.) Changing "global" to "tls" in these lines.

Apparently these lines were introduced in the following commit:

$ git show 4072572b0f8
commit 4072572b0f8aeffedcd908dc45b7e046ee0554b0
Author: Christophe Leroy <christophe.leroy at csgroup.eu>
Date:   Wed Nov 15 19:36:36 2023 +0100

    Fix stack-protector for powerpc
    
    On powerpc, stack protector expects a function called
    __stack_chk_fail_local() instead of __stack_chk_fail()
    
    And some versions of GCC for powerpc default to TLS canary
    instead of global canary, so always force GCC to use global
    canary with -mstack-protector-guard=global

Is it possible that this change made with PowerPC in mind is problematic for other architectures? I don't know if the sandbox build I'm going for targets, say, an emulated CPU or if it targets the x86 CPU of the build machine. Or is it more likely that a local change somewhere by a colleague is causing this?

Supporting this theory, https://maskray.me/blog/2022-12-18-control-flow-integrity states:

"The canary is stored either in a libc global variable (__stack_chk_guard) or a field in the thread
control block (e.g. %fs:40 on x86-64). Every architecture may have a preference on the location. In
a glibc port, only one of -mstack-protector-guard=global and -mstack-protector-guard=tls is
supported (BZ #26817)."

Thanks for any help,

Amy McLaughlin