On 2/3/26 6:39 PM, Florian Weimer wrote:
* H. J. Lu:
On Tue, Feb 3, 2026 at 12:26 AM Jason Merrill <[email protected]> wrote:
On 2/2/26 7:25 AM, H.J. Lu wrote:
On Sun, Feb 1, 2026 at 10:27 AM Jason Merrill <[email protected]> wrote:
On 1/31/26 8:11 PM, H.J. Lu wrote:
Change in the v8 patch:
1. __stack_chk_guard must be an uintptr_t variable.
2. Remove c_stack_protect_guard_decl_p and
duplicate_stack_protect_guard_decl_p.
Thanks.
@@ -926,7 +926,7 @@ default_stack_protect_guard (void)
t = build_decl (UNKNOWN_LOCATION,
VAR_DECL, get_identifier ("__stack_chk_guard"),
- ptr_type_node);
+ lang_hooks.types.type_for_mode (ptr_mode, 1));
Should this change be conditional on
targetm.stack_protect_guard_symbol_p ()?
Changed.
+ /* Define this to indicate that the stack protection guard symbol,
+ "__stack_chk_guard", is an internal symbol. */
+ if (targetm.stack_protect_guard_symbol_p ())
+ cpp_define (pfile, "__stack_protection_guard_is_internal_symbol__");
Why "internal"? I read "internal" as internal linkage, i.e. "static",
and in the testcases the symbols all have external linkage, and it's
based on TARGET_SSP_GLOBAL_GUARD.
Maybe the macro should be something like
__stack_protection_guard_declared__?
Changed.
Actually, do we need the macro at all? How will user code differ based
on whether it's defined? The existing ssp-global.c suggests that people
could already define __stack_chk_guard before this patch.
Florian, you asked for a macro. How will it be used?
I like to have a macro that tells us that in installed header files, we
can declare the guard variable with hidden visibility. It simplifies
the compile-time handshake between GCC and glibc.
But it seems like that was already possible; without this patch I can
add __attribute ((visibility ("hidden"))) to ssp-global.c and it passes.
I suppose I'm not entirely clear what the effect of this patch is; I
assume it's helpful to merge the user and built-in declarations rather
than use separate declarations with the same name, but I don't know
exactly how.
Jason
