[libc] add __stack_chk_guard to generic

[RossComputerGuy]

__stack_chk_guard is needed for many things and it's undefined so let's define it. If we need a more complex definition, we can do it per target or expand it. This is meant as a simple definition.

[llvmbot]

@llvm/pr-subscribers-libc

Author: Tristan Ross (RossComputerGuy)

Changes

__stack_chk_guard is needed for many things and it's undefined so let's define it. If we need a more complex definition, we can do it per target or expand it. This is meant as a simple definition.

---

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

1 Files Affected:

• (modified) libc/src/compiler/generic/__stack_chk_fail.cpp (+2)

diff --git a/libc/src/compiler/generic/__stack_chk_fail.cpp b/libc/src/compiler/generic/__stack_chk_fail.cpp
index c76ec1407ad356..68ab887afe3175 100644
--- a/libc/src/compiler/generic/__stack_chk_fail.cpp
+++ b/libc/src/compiler/generic/__stack_chk_fail.cpp
@@ -12,6 +12,8 @@
 
 extern "C" {
 
+uintptr_t __stack_chk_guard;
+
 void __stack_chk_fail(void) {
   LIBC_NAMESPACE::write_to_stderr("stack smashing detected\n");
   LIBC_NAMESPACE::abort();

[SchrodingerZhu]

Can you assign an arbitrary random number as its default value? It should be better than zero.

[RossComputerGuy]

Done, hopefully the number I gave is arbitrary and random enough heh.

[SchrodingerZhu]

I guess it is better to use static_cast<uintptr_t>(XXX); otherwise a warning will be triggered on 32bit targets

[RossComputerGuy]

Good idea, I added that now.

[SchrodingerZhu]

LGTM.

[llvm-ci]

LLVM Buildbot has detected a new failure on builder fuchsia-x86_64-linux running on fuchsia-debian-64-us-central1-a-1 while building libc at step 4 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/11/builds/10339

Here is the relevant piece of the build log for the reference

Step 4 (annotate) failure: 'python ../llvm-zorg/zorg/buildbot/builders/annotated/fuchsia-linux.py ...' (failure)

[nickdesaulniers]

Hardcoding a value like this is suspicious. At the very least, our startup code should be initializing this potentially using the AT_RANDOM value from the auxiliary vector...