On windows, when libc++ is statically linked into a dll the tls-key used for __cxa_eh_globals must be freed when the dll is unloaded. Otherwise the callback registered for the tls-key will remain in place but point to non-existing code and the process will crash as soon as a thread exits.
This will happen if libc++ is statically linked into the dll or if the main application doesn't use libc++ (so that is is unloaded when the dll is unloaded).
I've made a function __libcpp_tls_destroy() that is registered with atexit() that frees the tls-key. I did this conditionally on _LIBCPP_HAS_THREAD_API_WIN32 since I'm not sure how this should be handled for the other thread models.
I think a similar problem exists with the tls-key in __thread_specific_ptr, but a comment in the destructor (thread.h line 103) says that the missing cleanup is intentional in the pthreads case. And this destructor is inlined so I guess adding a cleanup there would be an ABI break?
Ok, so this is a new ABI entry in libcxx, but which only would be provided on certain platforms.
On one hand, this doesn't affect other platforms and their ABIs, and this is private API (used by libcxxabi) so it should probably be fine. But should we wrap it in a suitable ifdef to make it abundantly clear that it only is available in some cases?