[cfe-dev] [RFC] Suppress C++ static destructor registration

[Greg Parker via cfe-dev]

> On Jul 18, 2016, at 2:09 PM, Craig, Ben via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> There are guaranteed semantics for global destruction for well behaved programs.  First, thread locals are destroyed in LIFO order.  Then function level statics are destroyed in LIFO order. Then global and class statics are destroyed.
> 
> Here are some stackoverflow responses (with links to standardese) that can be useful:
> http://stackoverflow.com/questions/16010083/order-between-destruction-of-global-object-and-atexit-in-c
> http://stackoverflow.com/questions/38130185/is-it-legal-to-initialize-a-thread-local-variable-in-the-destructor-of-a-global
> 
> One area that I'm not clear on (and maybe this is what prompted your post) is what happens with regards to detached threads and global destruction.  To be honest, I think those programs (and detached threads in general) are broken for clean program termination use cases.
> 
> I'm not opposed to adding -fno-cxx-static-destructors... but I disagree with your current justifications.  Provide some concrete examples.

Concrete example:

The Objective-C runtime has a global table that stores retain counts. Pretty much all Objective-C code in the process uses this table. With global destructors in place this table is destroyed during exit(). If any other thread is still running Objective-C code then it will crash.

Currently the Objective-C runtime avoids the destructor by initializing this table using placement new into an aligned static char buffer.


-- 
Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160718/33006ca5/attachment.html>