[uClibc]cvs commit to uClibc/stdlib by andersen

[Erik Andersen]

On Fri Feb 09, 2001 at 09:45:46AM -0600, Manuel Novoa III wrote:
> Erik,
> 
> On Fri, 09 Feb 2001, andersen at cvs.uclinux.org wrote:
> > Revert stdio to initializing itself.  Not quite a pretty but that ensures that
> > we don't blow up by using too much stack space, and simplifies the job of
> > supporting new architectures, since they don't have to mess with calling foo
> > init functions in crt0 and cleaning up the resulting damage.
> 
> I know this is the safe way, but I really dislike the added overhead.  :-(

I knew you wouldn't like it <my appologies>.  But it just had to be done all
the same -- stuffing all this junk into the start code wasn't maintainable
(m68k was already out of date and we only support 3 archs so far -- imagine
what would happen when we support 10 arches and one of us decides we need
yet-another start function.  We would have to add it, using arch specific asm,
to 10 crt0.S files and manage to not trash the stack or trash any important
registers.  

I am the first to admit that I am weak at writing assembly, so one of my goals
is to get as much out of asm and into C as is possible.  The __init_stdio call
in crt0 ended up being really subtle about how it broke things since it makes a
bunch of calls which put a lot of stuff on the stack.  The more I thought about
it, the more convinced I became that __init_stdio and all other function calls
in crt0.S needed to be ripped out by the roots.

> What about having crt0 call something like __uClibc_main instead of main, where
> __uClibc_main is defined as
> 
> int __uClibc_main(int argc, char **argv, char **environ)
> {
> 	(call (possibly weak/null) initalization functions)
> 	(here to do stdio init if needed or to do)
> 	(any other general init for that matter)
> 
> 	return main(argc, argv, environ);
> }
> 
> This way the compiler takes care of the stack management/cleanup and we can
> still do stdio init only if necessary.  If space is really tight and you don't
> need stdio (or anything else that might be initialized here), you could just
> replace __uClibc_main by main in a custom crt0.S.
> 
> Would something like this address the problems that were coming up?  Do you see
> any drawbacks to this approach?

<ponders>

Yes.  I do like this approach very much.  I wish I'd thought of it! This allows
us to put back the sneaky initialization stuff, without having to encumber the
crt0 asm with piles of complicated junk to avoid trashing registers and not
blow the stack.  I dont see the need for an alternate crt0.S -- if we use weak
symbols then in the best case this function reduces to just a few extra
instructions of start code.  That I can live with, considering the benefits.  

Lets proceed with doing this.

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--