Windows: support more Mingw-w64 versions #2578
Conversation
Unit Test Results 32 files 220 suites 7m 41s ⏱️ Results for commit 207b6f3. ♻️ This comment has been updated with latest results. |
| switch("passC", "-fno-omit-frame-pointer") | ||
| switch("passL", "-fno-omit-frame-pointer") | ||
| if not defined(windows): | ||
| # ...except on Windows where the Nim bug doesn't manifest and this option |
There was a problem hiding this comment.
Why wouldn't the Nim bug manifest on Windows?
This is not a frequently appearing bug, but a theoretical risk in the way the conservative stack scanning is implemented that might result in a crash that would be extremely hard to track down.
There was a problem hiding this comment.
No pointer mangling in the Mingw version of glibc. See this issue for the mechanism: nim-lang/Nim#10625
There was a problem hiding this comment.
Can you point me to the documentation regarding the lack of pointer mangling in mingw? Perhaps there is some compile-time assertions that can added to the code to verify that.
There was a problem hiding this comment.
Glibc setjmp implementation, with mangling: https://github.com/lattera/glibc/blob/895ef79e04a953cac1493863bcae29ad85657ee1/sysdeps/x86_64/setjmp.S#L33
Mingw-w64 setjmp implementation, without any mangling: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/misc/setjmp.S
There was a problem hiding this comment.
A check for the definition of PTR_MANGLE would be a good additional precaution - it could be added at the bottom of the main nim module:
{.emit: """
#ifdef ASSUME_NO_PTR_MANGLE
#ifdef PTR_MANGLE
#error "This build assumes that pointer mangling is disabled. See config.nims for details"
#endif
#endif
""".}
arnetheduck
force-pushed
the
unstable
branch
2 times, most recently
from
657f9d5
to
a4667d1
Compare
|
There doesn't seem to be a compelling case for working around this gcc 8.x-specific bug, already fixed in gcc 9.1. If one reappears, this can be addressed at that point, but it's already been a year, and it's not proven necessary to fix. The more time passes, the less relevant some specific old MinGW or gcc version becomes. clang is also an increasingly viable alternative for Windows. |
No description provided.