* H. J. Lu:
> On Thu, Feb 5, 2026, 6:42 PM Florian Weimer <[email protected]> wrote:
>> Hmm, I'm probably thinking about this the wrong way. Once the
>> programmer uses -mstack-protector-guard=global, interoperability with
>> the current GNU/Linux toolchain is lost, whether we re-declare
>> __stack_chk_guard or not because glibc does not export that symbol on
>> x86-64 and several other architectures.
>
> Is the macro needed or not?
Would this work out as I expect?
(a) glibc starts exporting __stack_chk_guard@@GLIBC_2.44 (Optional)
(b) We add this to <stdc-predef.h>
#if defined __GNUC__
extern const unsigned long int __stack_chk_guard \
__attribute__ ((__visibility__ ("hidden")));
#endif
(Maybe for __clang__ as well, to be tested.)
(c) We add a compiled version of
const unsigned long int __stack_chk_guard = <magic goes here>;
to glibc's libc_nonshared.a.
My expectations are:
Without -mstack-protector-guard=global, current GCC will keep using the
guard value from TLS.
With -mstack-protector-guard=global, current GCC ignores the visibility
change. Depending on how things are linked, we either get a dynamic
reference to __stack_chk_guard@@GLIBC_2.44, or the linker will relax the
relocation against the libc_nonshared.a definition, and we get whatever
libc_nonshared.a produces for its magic ininitialization.
(If there's no __stack_chk_guard@@GLIBC_2.44 symbol, then of course
libc_nonshared.a becomes mandatory.)
With new GCC but without -mstack-protector-guard=global, behavior is as
with old GCC (use TLS).
With new GCC and -mstack-protector-guard=global, GCC honors the change
to hidden visibility, the libc_nonshared.a definition is now required,
and linker relaxation is avoided, leading to better code.
If that's the outcome, I don't think we need the macro after all.
Thanks,
Florian
