On Fri, 18 Dec 2020, Jeremy Drake via Mingw-w64-public wrote:
Have there been any further ideas on this? I am concerned the current state of affairs, accessing freed memory during tls destruction of objects in the .exe module, could cause crashes in objects more complicated than simple logging test cases. The proposed "patch 3" dealt with this when statically linked with winpthreads, but Windows called winpthreads.dll's callbacks before those from the main .exe module.
I haven't spent a lot of more time on it unfortunately, but I think my concluding thoughts were that it seems hard to get to work properly in this particular setup: As long as there's callbacks for both emutls for the allocations, and for __cxa_thread_atexit, they need to be handled by the same DLL, otherwise it's essentially impossible to guarantee that they run in the right order. Do you agree about that conclusion?
The pragmatic path forward in that case, I think, would to add a configure option to mingw-w64-crt for optionally enabling the __cxa_thread_atexit function. So if that's omitted from mingw-w64-crt, a new build of libstdc++ would include their version of it instead, and it should work as it used to, for better and worse.
For my llvm-mingw builds, I'd enable it, as the mingw implementation of __cxa_thread_atexit is highly windows specific, and I pretty much doubt that libcxxabi would be willing to integrate there. Just like on other platforms, the C runtime level layer provide the platform specific hooks for implementing the feature.
Having an optional component there isn't very nice, but would be at least some kind of practical way forward here. What do you think?
// Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
