[uClibc]Re: Quick question -- please reply soon.

Manuel Novoa III mnovoa3 at bellsouth.net
Fri Jan 5 23:10:38 UTC 2001


Erik,

> I'm guessing you saw the web page I put up and got concerned, right?
>     http://cvs.uclinux.org/uClibc.html

Actually, no.  I was just looking at ways to cut size and avoid checking if
stdio had been initialized every time one of the stdio routines was called.

> > I need to know:
> > 1) Is the use of weak symbols a problem?
> > 2) If not, what is your preferred method of using them?
> 
> Well, they do have some advantages (as you have noted) but there is a price to
> be paid (see http://www.bitwagon.com/elfvector.html for some discussion on this

I'll check this out.

> subject).  Furthermore, I plan on making full shared library support not just
> on x86, but also on MMU-less systems.  I have some ideas on how this can be
> done (a full blown discussion on this topic is invited some time).  
> 
> I've been working on the assumption that supporting weak symbols in that case
> wouldn't work, but as I think about it, I suppose those could be supported too.
> It just requires more code.
> 
> Any thoughts?  I'm open to allowing them or ruling them out.  Generally as I've
> gone through the code (esp code stolen from glibc) I've been throwing them out
> since they were, in nearly all cases, being overused/abused...

I agree that glibc seems to abuse them.  As far as shared librariies go, full
support would be nice.  However, in the short time I was looking at trying
something else which might be useful for low resource environments.  Given a
group of applications, you can find out which symbols are needed from uClibc,
and then with a special linker script build a rom-type (fixed memory location)
linked memory image of just those lib routines.  Then in a special _start
routine, map that file to a chosen shared memory location.   I was basically
thinking along the lines of the overlay example in the ld info file.  This way,
you would have a kind of shared library without having to lug all of the
symbols around.  The drawback is that you need to relink the apps whenever the
library changes.  

> No need to change.  If we decide to keep using weak symbols, then we will only
> use the __attribute__ for all C code, and ".weak foo" in asm (which we do not
> approve of but tolerate when we must).  pragmas are nasty.

Fine.  Then I should have a fairly large patch posted tomorrow.

Manuel






More information about the uClibc mailing list