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

[Sean Silva via cfe-dev]

On Mon, Jul 18, 2016 at 6:46 PM, Richard Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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).
>

To be clear, even on PS4, we would not default this flag to on, as there
are use cases that do exit. It would just be something that we suggest
users to try if it makes sense for them.

-- Sean Silva


> 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
>>
>
>
> _______________________________________________
> 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/caa1fc3a/attachment.html>