On Fri, Feb 6, 2026 at 7:25 PM Florian Weimer <[email protected]> wrote: > > * 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.)
I think libc_nonshared.a should be 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. I think so. -- H.J.
