| Issue |
129444
|
| Summary |
[RFC] [mingw-w64] Reduce stack protector overhead by marking `__stack_chk_guard` as DSO-local
|
| Labels |
platform:windows
|
| Assignees |
|
| Reporter |
alvinhochun
|
Currently `__stack_chk_guard` is not DSO-local on mingw-w64 target to support linking to libssp as a DLL, as per 78a57069b53a08d5aef98a8472fcfa73dbbc8771. 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:
```c++
#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
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
