[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