Re: crt0 formalization

[Jeff Johnston <jjohnstn at redhat dot com>]

jschopp wrote:
> > I would like to stress that newlib 1.15.0 is coming due.  
>
> First I'd heard of that.  Any idea when 1.15 is planned on being put 
> out?  I'd like to resync IBMs next cell developer SDK to be based on 
> newlib 1.15 instead of 1.14.

Releases are usually annual at the end of December.  I am more than open 
to making point releases to bring in major features that can't make it 
in time.

> I'd also like to have one of the solutions to fix atexit() pulling in 
> malloc merged for 1.15, assuming I didn't just miss something getting 
> merged for it.  I can write a new patch if you give me some direction 
> how you'd prefer it done.  This seems to be a good method: 
> http://sourceware.org/ml/newlib/2006/msg00181.html

Personally, I don't like the switch being used (tying it to whether you 
are doing something that uses malloc directly or indirectly).  I would 
much rather see it tied directly to the language (C++ dynamic, C static 
limited) or a user option (e.g. C++ dynamic, C static limited unless 
-mdynamic_atexit option is used).  The same weak symbol mechanism could 
be used, only it would be a special allocator hook routine.  The hook 
routine if supplied would simply call malloc/__malloc_r).  If not 
supplied, no call is made and the atexit routine fails.  You have one 
library and the behavior is well-defined.  On this line of thought, I 
was also thinking of allowing the size of the atexit group to be 
configurable (currently defaults to 32).  A storage-constrained target 
could tune this (e.g. choose static with no malloc and set upper-limit 
to a more-than-reasonable 128 or use malloc but set to only 3 at a time 
being allocated to extremely minimize initial storage required at the 
cost of ANSI 100% guaranteed 32 call compliance).

> I'd also like to take another run at getting the cell stdio offloading 
> RFC mergeable for 1.15, hopefully the whole thing but at least the 
> functions that don't take a FILE* argument.  This set of patches is 
> being used by end users, because without it something like printf() will 
> take ~200K of the 256K total memory, leaving very little for anything else.

Ok.

> > If the patch is accepted as-is, there is nothing to prevent the crti/n 
> > files from being added to gcc later (and later removed from 
> > libgloss).  If someone from the spu group wants to stand up and agree 
> > to make a gcc patch, I'll be happy to take the files out of the patch 
> > now and check the remainder in.
>
> Not that this is a democracy, because it isn't.  But I think all the spu 
> people are in favor of merging the patch here as is.  Kazunori-san had 
> some questions but seems to have had them answered.  I haven't heard any 
> objections from Andrew.  Ben sent the patch out in the first place, and 
> I liked them so much I forwarded them on.  Sa, the original author is 
> obviously in favor.  I talked privately to Ulrich Weigand who works on 
> spu gcc as well and he thought it was a logical split.
>
> Ultimately this is the group that will be maintaining the cell spu gcc & 
> newlib.

Ok, I am going to check the patch in.  Joel has made some good points 
and this does need to be discussed further on the gcc list.  I want to 
get this patch settled before 1.15.0 goes out and the alternative of 
fixing gcc can still be done post-1.15.0 without affecting users.

> > If this is attempting to evolve into a policy regarding what gcc must 
> > provide on their side of the fence, then I believe that it should 
> > probably move to the gcc list.
>
> That sounds like a good place for it.

-- Jeff J.