[uClibc]Re: a couple of fixes

[Manuel Novoa III]

Erik,

> > I think using crt0 across archs is a good idea.
> 
> I agree.  I will update my tree with the name change.

Good.  I'll keep an eye on the cvs archive and make the appropriate changes to
gcc-uClibc if you like.  There might be some other changes to be made.  See
below.

> BTW, re getting cvs commit priviledges -- If you visit 
>     http://cvs.uclinux.org/cvs_write.html
> and follow the directions I'll get you set up asap.

I'll take care of that today.

> > On the cross-arch front, it doesn't appear that weak symbols are available in
> > James Graves' environment.  I hate to give them up on i386 since they're so
> > convenient.  The best alternative I've come up with so far is to provide almost
> > empty object files which could be linked before the library.  For example, an
> > object file called something like omit_stdio.o could provide an empty
> > __init_stdio function, and could be linked before the library to avoid pulling
> > in the unused stdio code.  This could be done in conjuction with some
> > gcc-uClibc options to make the process easier -- say gcc-uClibc --no-stdio.
> > What do you think?  I'd still like to keep the weak symbol stuff where it is
> > supported.
> 
> I see -- so we would basically use ar to create a sort of fake weak-symbol
> support, since it will overwrite older objects with the same name.  So for
> arches lacking weak symbols, we simply include extra code into sysdeps/arch/foo
> to replace the weak-symbol-ified junk, and make sure sysdeps is compiled/added
> to libc.a last.  That is twisted, evil, and wrong.  I like it.  :-)

That wasn't really what I was thinking.   Here's a revised version.  Suppose
we're dealing with an arch that doesn't support weak symbols.  Now, build
libc.a with getopt.o but also build gnu-getopt.o and put it in
uClibc/object-overrides or some-such. Then, say you wanted to build a program
which didn't use stdio but did use gnu-getopt. You could do something like
      
   gcc-uClibc-{ARCH} -DUCLIBC_NO_STDIO -DUCLIBC_GNU_GETOPT myprogram.c

gcc-uClibc could either rebuild crt0.o excluding __init_stdio or it could add a
dummy __init_stdio that just returned by inserting
uClibc/object-overrides/omit_stdio.o in the link order before libc.a.  It would
also insert uClibc/object-overrides/gnu-getopt.o in the link order before
libc.a.

Actually, rebuilding crt0.o might not be a bad idea even when we have weak
symbol support.  We would have to decide on what the default behavior of the
library would be.  Perhaps we should default to full-featurered and allow the
user to tune the size?

Of course, if we used the omit_stdio.o approach, the user should get a linking
error if they did use stdio because other symbols needed would try to pull in
the normal _stdio_init.o and there should be a duplicate symbol error.

> > One unrelated question -- do you think there is any reason to keep
> > sys_errlist[] as is?
> 
> Hmm.  We do lose some compatibility here.  There are a number of (admittedly
> misguided) app that use sys_errlist[] directly.  Of course, if we throw out
> compatibility with broken apps, we can move this crap so it it read in from a
> text file in a known filesystem location, causing only one copy to need to
> exist per system.  Hmm.  That won't be all that helpful when we get shared libs
> though, since we will only need one copy then too... 

Sorry.  I was a bit vague.  I wasn't talking about a general data compression
routine or having a seperate file.  Because of the nature of the data, i.e. not
likely to change very often and uses only a small subset of the available
character codes, it would be very easy to pack the data.  I was thinking of
using 4 bit groups so that the 15 most frequent characters would take half a
byte, and the others could be escaped.  That would give you roughly a 30-40%
savings in space on the strings, with only a small amount of code needed to
unpack them.  You can do even better if you pull out all the unique words and
compress only them, and then represent the error messages as a block of indices
into the word table.  I've thought about it some more and I'm sure ;-) I can
cut about 2k off the object file size.  I'll work on that today and
hopefully post some code this evening.  Note that this would be dynamically
generated at build libc.a build time so as to include any changes to
sys_errlist.c.

If someone needed sys_errlist[], we could override via weak symbols or do
something with gcc-uClibc as discussed above.

Manuel