[PATCHv3] librt: Add posix_spawn support

Rich Felker dalias at aerifal.cx
Sat Apr 28 04:26:02 UTC 2012


On Fri, Apr 27, 2012 at 11:57:38PM -0400, Mike Frysinger wrote:
> On Friday 27 April 2012 19:59:34 Rich Felker wrote:
> > On Fri, Apr 27, 2012 at 07:35:11PM -0400, Mike Frysinger wrote:
> > > On Friday 27 April 2012 18:33:08 Rich Felker wrote:
> > > > But nowadays it's
> > > > just really annoying and harmful. With shared libraries, it adds bloat
> > > > and load time to every program which wants to use clock_gettime for
> > > > getting system time, which is every modern program.
> > > 
> > > i'd side with the clock_* funcs being better in libc because they are
> > > getting used more and more as people transition away from gettimeofday()
> > 
> > And they are NOT part of any optional realtime option in POSIX;
> > they're a mandatory part of POSIX base.
> 
> afaik, POSIX doesn't cover library layout in any way.  there is nothing 
> requiring us to stick all mandatory interfaces into -lc.  after all, much of 
> the math support falls into this category yet lives in -lm.

Actually, to some extent it does. See the documentation for the c99
command:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html

POSIX allows certain -l options (which need not exist as a physical
library file in the filesystem) to be required for using certain
features; a conformant application (i.e. build script) must use them,
but the implementation is not required to hide the symbols from you if
you don't include them, and in fact it's perfectly conformant for them
all to be ignored (i.e. everything available in the default
library/libraries).

> > > it would be really cool if we could split lesser used and standalone code
> > > into standalone shared libraries and libc.so was a simple linker script
> > > that pulled in all the other objects AS_NEEDED(...).  but alas, that'd
> > > play havoc with ABI/SONAMEs.
> > 
> > I don't understand how this is all that useful. If you have binaries
> > on your system that use standard functionality X, you'll have to have
> > it _somewhere_ anyway, and it might as well be in libc.so. If you're
> > worried about rare functions being spread out across lots of pages
> > that might also contain widely-used functions and increasing average
> > paged-in memory usage, it would be possible to add section attributes
> > to all the rare stuff to put it all in one contiguous part of libc.so
> > that would only be paged-in when stuff is actually using it.
> 
> not everyone have virtual memory :p.  ignoring that, larger single libraries 
> means more reloc processing at init, and more string space to search when 
> resolving symbols.
> -mike

I would suspect on a system without virtual memory, you'd decide to
completely omit certain functionality from uClibc at config/build
time if you don't need it for any of your bins. If you do need it for
some of your bins, overall memory usage will almost surely be lower by
having it in a common .so file rather than having another .so loaded
in memory.

As for reloc processing, that's essentially zero if you use visibility
(or -Bsymbolic-functions, the big stick) to bind as much as possible
at .so creation time.

String space is possibly an argument against including too much; I'm
not sure. I'll grant that there may be *some* arguments against
integrating it all into either libc.so or libpthread.so, but I think
those arguments are looking pretty weak compared to the arguments FOR
doing it.

Rich


More information about the uClibc mailing list