[RFC] [mingw-w64] Reduce stack protector overhead by marking `__stack_chk_guard` as DSO-local

[alvinhochun]

Currently __stack_chk_guard is not DSO-local on mingw-w64 target to support linking to libssp as a DLL, as per 78a5706. As a result, the stack protector code needs to perform an additional address dereference through the .refptr stub, compared to MSVC target.

Since mingw-w64 v11, the functionality of libssp has been integrated into mingw-w64-crt, so libssp is no longer necessary and __stack_chk_guard is guaranteed to be statically linked. Therefore, I suggest we should start marking __stack_chk_guard as DSO-local in LLVM 21 to remove the need to go through .refptr, which should give a slight performance boost when stack protector is used.

Demo code:

#ifdef DSO_LOCAL_STACK_CHK_GUARD
void *__stack_chk_guard __asm__("__stack_chk_guard");
#endif

extern "C" void other(void *);

int func(int v) {
    int buf[16];
    buf[0] = v;
    other(buf);
    return *buf;
}

Output: https://godbolt.org/z/5xhsKPqhG

Backward compatibility issues:

By the time LLVM 21 releases, mingw-w64 v11 would have been released for over 2 years. Nevertheless, some users may be stuck with an older version of mingw-w64 runtime, so we need to consider the backward compatibility.

• If libssp is linked statically, this will still work normally.
• If libssp is linked dynamically, then the linker is forced to generate 32-bit pseudo relocations for __stack_chk_guard, and on x86_64, these can fail during run-time if the address offset is larger than 32-bit. LLD does emit warnings for them. This is a breaking change. (The user can work around this by linking libssp statically.)

Is this acceptable?

CC @mstorsjo @lhmouse @lazka @brechtsanders

[lazka]

no objections here

[lhmouse]

@alvinhochun

By the time LLVM 21 releases, mingw-w64 v11 would have been released for over 2 years. Nevertheless, some users may be stuck with an older version of mingw-w64 runtime, so we need to consider the backward compatibility.

My experience is that prebuilt Clang packages (msys2, llvm-mingw, winlibs) which target mingw-w64 usually link against recent enough mingw-w64 CRT, and those which link against old versions don't provide Clang. AFAICT the impact is minimal.

[mstorsjo]

Since mingw-w64 v11, the functionality of libssp has been integrated into mingw-w64-crt, so libssp is no longer necessary and __stack_chk_guard is guaranteed to be statically linked.

This is only guaranteed as long as one doesn't link in GCC's libssp at the same time.

And after discussing this on IRC last time, I have a couple new concerns.

As pointed out by @lazka on IRC, most distros still do ship GCC's libssp in their GCC+mingw-w64 environments. And even if GCC's libssp is redundant these days, that doesn't stop a regular GCC build from installing it (I guess that would require something like --disable-libssp in the GCC/runtimes build, not sure if that's a thing or not).

Secondly; out of tradition, both GCC and Clang link with -lssp -lssp_nonshared, if pass -fstack-protector-strong when linking. Mingw-w64 doesn't provide those, so in llvm-mingw, I e.g. provide them with dummy empty static libraries: https://github.com/mstorsjo/llvm-mingw/blob/20250227/build-mingw-w64.sh#L143-L148 Not sure what other toolchains do, though. Toolchains that don't build the GCC runtimes obviously won't have this issue, but ones that do probably still will.

I also tried on a stock Ubuntu 24.04 install (which does have mingw-w64 v11); I did /usr/bin/clang -target x86_64-w64-mingw32 test/stacksmash.c -o stacksmash.exe -v -fstack-protector-strong, and it does link in __stack_chk_guard from libssp-0.dll.

So even though GCC's libssp isn't really needed these days, this is practically what will get linked in many cases.

So if we want to move forward with this, I unfortunately think we would need to sort out a more complete strategy to migrate all users away from GCC's libssp before we could do that.