Re: PATCH: Disable dynamic allocation in atexit

[Jeff Johnston <jjohnstn at redhat dot com>]

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,