On Fri, 11 Sep 2026, LIU Hao wrote:
From 38be1b2300f8647e8db6e9268a643ed5dbf02b77 Mon Sep 17 00:00:00 2001
From: Timo Rothenpieler <[email protected]>
Date: Wed, 9 Sep 2026 14:16:34 +0200
Subject: [PATCH] ssp: prioritize stack guard init constructor
Other libraries might also be running constructors, which themselves are
built with SSP enabled,
or are calling functions that are.
If those then get ordered befor the ssp constructor, they might crash due to
the yet to be initialized
__stack_chk_guard.
This at least affects a statically linked glib, which launches a background
thread in the
libgio constructor.
If the ssp constructor then runs at a random point after, it initializes the
stack guard, and once
the thread returns from whatever function it's in, it crashes because the
stack guard changed.
Signed-off-by: Timo Rothenpieler <[email protected]>
---
mingw-w64-crt/ssp/stack_chk_guard.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-crt/ssp/stack_chk_guard.c
b/mingw-w64-crt/ssp/stack_chk_guard.c
index 499f0033b..adffb537b 100644
--- a/mingw-w64-crt/ssp/stack_chk_guard.c
+++ b/mingw-w64-crt/ssp/stack_chk_guard.c
@@ -10,6 +10,11 @@
uintptr_t __stack_chk_guard = 0;
+#if defined(__GNUC__) && __GNUC__ >= 9 && !defined(__clang__)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wprio-ctor-dtor"
+#endif
The !defined(__clang__) part of the ifdef is slightly redundant, as Clang
currently identifies as GCC 4.2, so it wouldn't ever pass the rest of the
condition. But I guess it's ok for clarity anyway.
@@ -21,7 +26,7 @@ __attribute__((__no_stack_protector__))
-fstack-protector* options from CFLAGS.
# endif
#endif
-__attribute__((__constructor__))
+__attribute__((constructor(0)))
static void __cdecl init(void)
{
unsigned int ui;
This looks ok to me.
As discussed in the github PR where this originated
(https://github.com/mingw-w64/mingw-w64/pull/186), it could be worth
considering calling the constructor even earlier (either through the
.CRT$XC<char> sections, or through a direct init call even earlier). But
this change in itself should probably be good enough for now.
And as pointed out there, initializing it late isn't a problem in itself
unless someone starts a thread, where the start of the thread can use one
value of the guard and the end of it uses another.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
