[PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

[Tavian Barnes via cfe-commits]

tavianator marked 3 inline comments as done.
tavianator added a comment.

In http://reviews.llvm.org/D21803#470448, @bcraig wrote:

> What that means for this implementation is that I think that _cxa_thread_atexit is allowed to be called during run_dtors.  If running the dtor for a thread local variable 'cat', we encounter a previously unseen thread_local 'dog', the compiler will call the ctor, then register the dtor with _cxa_thread_atexit.  Since it is the most recently constructed thread local object, I would expect the 'dog' dtor to be the next dtor to be run.  You may be able to support this just by moving "elem = elem->next" below the dtor invocation.


It wasn't quite that easy (have to re-look at the pthread_key to get newly added thread_locals), but that's done in the latest patch.


================
Comment at: src/cxa_thread_atexit.cpp:115
@@ +114,3 @@
+    if (!dtors_atexit) {
+      if (__cxa_atexit(run_dtors_atexit, NULL, __dso_handle) != 0) {
+        return -1;
----------------
See http://stackoverflow.com/q/38130185/502399 for a test case that would trigger this.  This may not be necessary depending on the answer to that question.

================
Comment at: src/cxa_thread_atexit.cpp:122
@@ +121,3 @@
+    auto head = static_cast<DtorList*>(std::malloc(sizeof(DtorList)));
+    if (!head) {
+      return -1;
----------------
This has changed somewhat in the latest patch, but the gist is similar.  If libc++abi.so is dlclose()d, there had better not be any still-running threads that expect to execute thread_local destructors (or any other C++ code, for that matter).  In the usual case (libc++abi.so loaded at startup, not by a later dlopen()), the last run_dtors() call happens as the final thread is exiting.


http://reviews.llvm.org/D21803