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

[Richard Smith via cfe-dev]

On Mon, Jul 18, 2016 at 5:37 PM, James Knight via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> That sounds like a nice idea. The standards-required behavior of tearing
> down globals is insane, and it'd sure be nice to be able to easily opt out
> of the insanity. It'd be nicest if it was supported in both GCC and Clang
> with the same flag, of course. :)
>
> std::quick_exit is just about worthless, because there's just about no
> practical way that you can ever get all the code linked into your binary to
> stop calling exit().
>

Recompiling all the code linked into your binary with a custom compiler
flag is also not the most practical thing to ask of people. Maybe a more
practical approach would be to register an atexit handler that calls
quick_exit? :)


> IMO, the standard should just entirely remove the utterly broken global
> destructors "feature".
>

Perhaps so, but creating a non-standard dialect of C++ with different
semantics has historically proven to not be a viable way to get that
effect. This change will create portability headaches down the line, as
other flags to turn off parts of standard C++ semantics have done
(-fno-rtti, -fno-exceptions). And evidence from those suggests that the
standard never does actually get fixed, and each vendor ends up with a
slightly different mode.

If someone's prepared to write up a paper for the C++ committee exploring
what it would mean to standardize this behaviour and actually fix the
problem for everyone, it would seem extremely reasonable for clang trunk to
carry a flag to enable that behaviour (and it certainly doesn't have to
wait for the committee to respond).

In the "interim", a compiler flag is nice because you can set it in your
> build system, and all your existing code just starts working better (where
> better = fewer random unreproducible crashes on shutdown when someone
> accidentally used a global with a destructor). And you don't ever have to
> worry about this problem again...


... until you try to use a library that depends on a global destructor
running on program shutdown :) For previous similar flags, there was a
small but perpetual cost paid by every compiler vendor and by users, for
each of these features that got into mainstream use -- and I expect this
*will* enter mainstream use (it would be a very convenient solution to a
selection of important problems).

> On Jul 18, 2016, at 4:39 PM, Bruno Cardoso Lopes via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >
> > Hi,
> >
> > C++ static destructors can be problematic in multi-threaded
> > environment. Some of the issues users often complain about include:
> > 1. Teardown ordering: crashes when one thread is exiting the process
> > and calling destructors while another thread is still running and
> > accessing the destructing variables
> > 2. Shared code that is compiled both as an application and as a
> > library. When library mode is chosen, goto (1).
> > 3. Some projects currently override __cxa_atexit to avoid the behavior
> > in question.
> >
> > To get around that, I propose we add a compiler option (e.g.
> > -fno-cxx-static-destructors) to allow clang to suppress destructor
> > registration (currently done via __cxa_atexit, atexit):
> > https://reviews.llvm.org/D22474
> >
> > I'm opening this discussion here on cfe-dev to get some feedback on the
> matter
> >
> > One can argue that dealing with C++ static destructors in
> > multi-threaded environment is solely the responsibility of the
> > developer, however since (AFAIK) we don't have any standard guaranteed
> > semantic for "global destruction vs. threads", it seems fair to me
> > that we could give developers some option.
> >
> > Cheers,
> >
> > --
> > Bruno Cardoso Lopes
> > http://www.brunocardoso.cc
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160718/111d5ea8/attachment.html>