PATCH: Disable dynamic allocation in atexit

[Jeff Johnston]

Jeff Johnston wrote:
> Mark Mitchell wrote:
> 
>> Jeff Johnston wrote:
>>
>>> Mark,
>>>
>>>  The patch is fine, but it's got me thinking I want to do a bit more.
>>
>>
>>
>> To be 100% clear, I'm interpreting that as approval, and I'll check it
>> in.  If that's not OK, shout!
>>
> 
> I had meant for you to wait.  There should at least be a way to default 
> this for a platform in configure.host.  See newlib_io_pos_args for an 
> example unless you want me to do it.
>

Looks like I just missed you checking in the change.

>>
>>>  The one question I am pondering is whether to make
>>> static-only-32-entry, the default for non-_REENT_SMALL platforms.
>>> Normally I preach backwards-compatibility, but I can't think of any
>>> applications off-hand that should require more than 32 entries.  This
>>> makes the empty program compact by default which I think is a good 
>>> thing.
>>
>>
>>
>> One thing to bear in mind is that C++ applications will register an
>> atexit function for every statically allocated object with a destructor.
>>  For example:
>>
>>   struct S { ~S(); };
>>   S s;
>>
>> will result in an atexit call to clean up "s".
>>
> 
> I hadn't thought about destructors so it is clear I should stick with 
> dynamic being the default for both _REENT_SMALL and non-_REENT_SMALL.
> 
> 
>> So, I think in medium-size C++ applications, it's easy to get more than
>> 32 slots.  ARM has invented a way for the compiler to collaborate to say
>> how many slots are needed so that the linker can allocate just the right
>> number.  This is a good trick, and we should implement it at some point.
>>  (Even though it was originally designed for ARM, it could be made to
>> work on all platforms.)
>>
>> I'm not sure whether it makes sense to implement your plan before this
>> feature is added; you understand the userbase better than I.
>>
> 
> 
>> Thanks,
>>
>