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

[Erik Pilkington via cfe-dev]

I've put a patch up for this here: https://reviews.llvm.org/D50994

Thanks!


On 7/16/18 2:55 PM, JF Bastien via cfe-dev wrote:
> Hi folks,
>
> I’d like to add a flag in clang, -fno-cxx-static-destructors,  which 
> allows developers to demand that no static destructors be emitted. 
> Bruno has a sample implementation <https://reviews.llvm.org/D22474>. 
> We’ve discussed this previously 
> <http://lists.llvm.org/pipermail/cfe-dev/2016-July/050040.html> but 
> I’d like to re-open the discussion and make a different case for it 
> because we’ve received more requests for such a feature.
>
>
> *Why is this desirable?*
>
> In low-memory circumstances it’s often the case that we know that 
> static global destructors are never called. It would be useful to 
> avoid emitting them entirely to save memory. We can’t necessarily make 
> the types themselves trivially destructible (e.g. a std::map, or a 
> type that’s used both as a global and as an automatic variable for 
> which the destructor is only meaningful when automatic, or coming from 
> 3rd party library such as boost), and using a NeverDestroyed<T> class 
> or global pointer only (std::string& foo = *new std::string(“derp");) 
> prevents constexpr and is annoying boilerplate (and again, 3rd party 
> code breaks that party).
>
> This is also useful for some thread-related use cases: we have 
> empirical evidence that threads using globals cause crashes if these 
> globals are being destroyed.
>
> Thread-local storage is similarly painful for different reasons. I’m 
> not proposing that anything be done yet, but let’s keep it in mind.
>
>
> *Developers want this?*
>
> Yes, we’ve received numerous requests for this. Developers are worried 
> about code footprint, and have numerous crash reports they’d like to 
> get rid of. Developers tell us they’d really rather not pay for this 
> feature, because they don’t want to use it yet are stuck with it (and 
> C++ is a “don’t pay for what you don’t use” language).
> Interesting note: developers are used to having no cleanup on 
> termination on platforms where applications can get terminated when 
> e.g. they’re sent to the background by user action.
>
>
> *Concrete example*
>
> Greg Parker provided this example of thread-related issues in the 
> previous discussion:
>
>     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.
>
>
> I’m assuming that the embedded usecase is obvious enough to everyone 
> to not need an example. Let me know if that’s not the case.
>
>
> *What about standardization?*
>
> If this works out I'll discuss standardization options through SG14 
> (and then WG21). The type of developer who’s asked for this are 
> typical SG14 targets (embedding, gaming, etc). This might fit in with 
> “freestanding” or other similar SG14 efforts, but we need experience 
> to guide the proposal. Maybe EWG will be interested as well? 🤷‍♂️
>
>
> Thanks,
>
> JF
>
>
> _______________________________________________
> 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/20180820/5f37c98b/attachment.html>