PATCH: Disable dynamic allocation in atexit

[Jeff Johnston]

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.

> 
>>  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,
>