<div dir="ltr">+1 for a [[no_destroy]] attribute. There are a couple of places libc++ could benefit from having it, but we couldn't turn of static destructors in general.<div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 17, 2018 at 11:54 AM Ben Craig via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-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">My interpretation of the C++ standard is that today's freestanding C++ implementations (between C++98 and C++17) are already allowed to skip global destructors.  <a href="http://eel.is/c++draft/basic.start#main-1" rel="noreferrer" target="_blank">http://eel.is/c++draft/basic.start#main-1</a><br>
<br>
So re-label the toolchain from hosted to freestanding, change nothing else except start-up and termination, and you still have a compliant (but unorthodox) implementation.<br>
<br>
I've got a paper that discusses some of this (along with a lot of other embedded-hostile features) here: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1105r0.html" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1105r0.html</a><br>
<br>
<br>
> -----Original Message-----<br>
> From: cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>> On Behalf Of David Chisnall<br>
> via cfe-dev<br>
> Sent: Tuesday, July 17, 2018 2:15 AM<br>
> To: JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>><br>
> Cc: <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>; Bruno Cardoso Lopes <<a href="mailto:blopes@apple.com" target="_blank">blopes@apple.com</a>><br>
> Subject: Re: [cfe-dev] [RFC] Suppress C++ static destructor registration<br>
> <br>
> On 16 Jul 2018, at 22:55, JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
> wrote:<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 thread is<br>
> 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>
> > I’m assuming that the embedded usecase is obvious enough to everyone<br>
> to not need an example. Let me know if that’s not the case.<br>
> <br>
> I have hit this issue a few times with similar solutions (either placement new,<br>
> or simply new and leak the pointer), so I agree that this is a problem that<br>
> needs solving.  That said, I rarely want to disable *all* static destructors,<br>
> instead I want to either disable some or define ordering between them<br>
> (which I can do by disabling some and explicitly calling them from another).<br>
> <br>
> I would much prefer to see a [[no_destroy]] attribute or similar, to disable<br>
> registering destructors for a specific static / global, than a different language<br>
> mode.  I would also see a simplification of some code with a<br>
> [[lazy_construct]] attribute so that I could declare a global and have it follow<br>
> the same initialisation rules as a static, rather than having to create a static<br>
> and a function that returns a reference to it.<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 a<br>
> 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 to see<br>
> 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 objects<br>
> have been destroyed when the library is unloaded?<br>
> <br>
> David<br>
> <br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-</a><br>
> 2Dbin_mailman_listinfo_cfe-<br>
> 2Ddev&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8<br>
> mub81SfUi-UCZRX0Vl1g&m=HxCl5f-t-<br>
> UkQZp2CkeD_xRdlXcwFkEmw0QbDAVUlQ64&s=M4RhJONiFXWSmezJsv1xLQ<br>
> oNt--UJoWYQ2vVyn7s730&e=<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>