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

[Dean Michael Berris via cfe-dev]

+1

FWIW, I'm in favour of an attribute alongside/instead of this to mark
which objects should not have their destructors emitted/called (can
apply to function-local static and thread_local objects in C++). I've
had to manually do this a number of times and would appreciate this
extension.

Cheers
On Tue, Jul 17, 2018 at 8:48 AM James Y Knight via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> +1 on adding this functionality.
>
> HOWEVER, I think the example of an object (e.g. the objc runtime table) which you'd like to not destroy is a rather poor motivating example for the addition of a compiler flag, and would suggest that you rewrite your motivation without that example in it.
>
> The reason to add a compiler-flag is to enable compiling all your code in that way -- e.g. if you know you want to _never_ emit global destructors in your application.
>
> For the objc-runtime table, using a "template <typename T> class NoDestructor" template which does a new-into-std::aligned_storage dance seems like an entirely suitable answer. Or, if that's not good-enough for some reason, then it'd seem to call for the addition of an attribute to suppress the destructor on the one global it's attached to.
>
>
> On Mon, Jul 16, 2018 at 5:55 PM JF Bastien via cfe-dev <cfe-dev at lists.llvm.org> 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. We’ve discussed this previously 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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



-- 
Dean