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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
