<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Wed, 18 Jul 2018, 12:33 Aaron Ballman via cfe-dev, <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jul 17, 2018 at 5:06 PM, JF Bastien via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>> wrote:<br>
> Replying to everyone so far. Thanks for the input!<br>
><br>
> Based on feedback reveiced I think it makes sense to have an attribute, and<br>
> I’m happy to implement it. I also think a flag makes sense based on<br>
> developer feedback, and based on Ben’s reading of the standard for<br>
> freestanding. I don’t think we want to change the freestanding behavior (at<br>
> least not before C++20 cleans it up), but having a flag to control this<br>
> behavior makes sense.<br>
><br>
> I therefore think we should pursue both.<br>
><br>
> On attributes: I like this attribute for globals, function statics, and TLS.<br>
> I don’t like it at all for automatic variables, because RAII is fundamental<br>
> to C++. I think we should limit where the attribute can be used.<br>
><br>
> Attribute name bikeshed: anyone care for one of<br>
><br>
> [[no_destroy]]<br>
> [[indestructible]]<br>
> [[forever]]<br>
> [[undying]]<br>
> [[RAINI]] (Resource Acquisition Is Not Initialization)<br>
><br>
> ?<br>
<br>
Out of that list, I think [[no_destroy]] resonates with me the most,<br>
but I don't have a strong preference. Other alternatives:<br>
<br>
[[destructor_not_run]]<br>
[[not_destroyed]]<br>
[[no_cleanup]]<br>
<br>
One question I have about any of these names is: can we check some<br>
very large bodies of code to ensure there are no use macros with the<br>
same spelling as whatever we seriously consider?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Another thing we should consider: if we add both an attribute and a flag, some users will reasonably want an attribute to undo the effect of the flag. So we should pick a name for the attribute that supports a negative form (either attr vs attr(false) or attr vs no_attr or something like that).</div><div dir="auto"><br></div><div dir="auto">It'd also seem preferable to give the attribute and the flag names that parallel one another, if we can do so without sacrificing name quality. (Strawman: [[clang::no_destroy]] and -fno-destroy-statics)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Compiler flag name bikeshed: I’m happy with -fno-c++-static-destructors as<br>
<br>
I'd be happy with that flag name.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Do we anticipate ever registering destructors for global ARC pointers (or structs containing same)? If so, we may come to regret giving the flag a C++-specific spelling.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
~Aaron<br>
<br>
> Richard suggests.<br>
><br>
><br>
> Individual replies:<br>
><br>
> Richard said:<br>
><br>
> Conversely, code (I'm also thinking particularly of third-party code) not<br>
> written to deal with no cleanup on termination may fail to flush buffers or<br>
> save changes to its configuration or the like, resulting in data loss. So<br>
> the user needs to do some work at some level -- either to verify it's safe<br>
> to turn this option on, or to change the code to avoid non-trivial<br>
> destruction -- and that work scales with the quantity of pre-existing<br>
> non-trivial destructors. Nonetheless, this flag may still be the most<br>
> pragmatic way to address the problems in question after determining that<br>
> it's safe to use it.<br>
><br>
><br>
> Agreed. Luckily some platforms already terminate program abruptly. These<br>
> applications already deal with those issues :-)<br>
><br>
> On the standardization front, I think there is a path to changing ISO C++<br>
> that has at least some chance of success:<br>
> 1) Add an annotation mechanism to say "this variable intentionally has a<br>
> non-trivial destructor that must be run at shutdown" and another to say<br>
> "this variable should not have its destructor run at shutdown even though<br>
> it's non-trivial"<br>
> 2) Deprecate variables with a non-trivial destructor without one of those<br>
> annotations<br>
> 3) (After some time has passed) switch the default from running destructors<br>
> to not running destructors<br>
><br>
><br>
> This path is interesting. I’ll write a paper for the next mailing, or during<br>
> the meeting, based on clang implementation experience and any usage I can<br>
> get between now and then. I’ll make sure to mention your suggestion.<br>
><br>
> David said:<br>
><br>
> I would; however, point out that exit() is not the only time that static<br>
> destructors are run.  The C++ standard pretends that shared libraries don’t<br>
> exist (and added thread-local variables with nontrivial destructors in such<br>
> a way that gives implementers two possible bad choices if they have to<br>
> support library unloading), but in the real world they do.  It’s difficult<br>
> to see how such a mode would coexist with a world that supports loading and<br>
> unloading of shared libraries.  Perhaps a sanitiser could check that the<br>
> objects have been destroyed when the library is unloaded?<br>
><br>
><br>
> I’d like to keep shared libraries out of scope of this discussion.<br>
><br>
><br>
><br>
> On Jul 16, 2018, at 2:55 PM, JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>><br>
> wrote:<br>
><br>
> Hi folks,<br>
><br>
> I’d like to add a flag in clang, -fno-cxx-static-destructors,  which allows<br>
> developers to demand that no static destructors be emitted. Bruno has a<br>
> sample implementation. We’ve discussed this previously but I’d like to<br>
> re-open the discussion and make a different case for it because we’ve<br>
> received more requests for such a feature.<br>
><br>
><br>
> Why is this desirable?<br>
><br>
> In low-memory circumstances it’s often the case that we know that static<br>
> global destructors are never called. It would be useful to avoid emitting<br>
> them entirely to save memory. We can’t necessarily make the types themselves<br>
> trivially destructible (e.g. a std::map, or a type that’s used both as a<br>
> global and as an automatic variable for which the destructor is only<br>
> meaningful when automatic, or coming from 3rd party library such as boost),<br>
> and using a NeverDestroyed<T> class or global pointer only (std::string& foo<br>
> = *new std::string(“derp");) prevents constexpr and is annoying boilerplate<br>
> (and again, 3rd party code breaks that party).<br>
><br>
> This is also useful for some thread-related use cases: we have empirical<br>
> evidence that threads using globals cause crashes if these globals are being<br>
> destroyed.<br>
><br>
> Thread-local storage is similarly painful for different reasons. I’m not<br>
> proposing that anything be done yet, but let’s keep it in mind.<br>
><br>
><br>
> Developers want this?<br>
><br>
> Yes, we’ve received numerous requests for this. Developers are worried about<br>
> code footprint, and have numerous crash reports they’d like to get rid of.<br>
> Developers tell us they’d really rather not pay for this feature, because<br>
> they don’t want to use it yet are stuck with it (and C++ is a “don’t pay for<br>
> what you don’t use” language).<br>
> Interesting note: developers are used to having no cleanup on termination on<br>
> platforms where applications can get terminated when e.g. they’re sent to<br>
> the background by user action.<br>
><br>
><br>
> Concrete example<br>
><br>
> Greg Parker provided this example of thread-related issues in the previous<br>
> discussion:<br>
><br>
> The Objective-C runtime has a global table that stores retain counts. Pretty<br>
> much all Objective-C code in the process uses this table. With global<br>
> destructors in place this table is destroyed during exit(). If any other<br>
> thread is still running Objective-C code then it will crash.<br>
><br>
> Currently the Objective-C runtime avoids the destructor by initializing this<br>
> table using placement new into an aligned static char buffer.<br>
><br>
><br>
> I’m assuming that the embedded usecase is obvious enough to everyone to not<br>
> need an example. Let me know if that’s not the case.<br>
><br>
><br>
> What about standardization?<br>
><br>
> If this works out I'll discuss standardization options through SG14 (and<br>
> then WG21). The type of developer who’s asked for this are typical SG14<br>
> targets (embedding, gaming, etc). This might fit in with “freestanding” or<br>
> other similar SG14 efforts, but we need experience to guide the proposal.<br>
> Maybe EWG will be interested as well? 🤷‍♂️<br>
><br>
><br>
> Thanks,<br>
><br>
> JF<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div>