Re: libstdc++ wants clock_gettime without libpthread

[Mike Frysinger <vapier at gentoo dot org>]

On Thursday 18 October 2012 20:22:46 Roland McGrath wrote:
> 1. Just move clock_* calls into libc.
> 
>    Pro: That solves the problem for libstdc++ with almost no special effort
> 	at all on the libstdc++ side.  If building libstdc++ just uses -lc
> 	-Wl,--as-needed -lrt then it will be compatible with old
> 	installations where you need to get it from librt, and with new
> 	ones where you can get it from libc and won't generate a DT_NEEDED
> 	on librt.so.N (without requiring configure-time checks to influence
> 	the linking details).
> 
>    Con:
>    a. It bloats libc.so.N with code, and its permanent ABI with symbols,

i don't think the additional bloat is large.  on x86_64:
$ readelf -sW /lib64/librt.so.1  | awk '$NF ~ /clock_/ { print $3,$NF }'
75 clock_getres@@GLIBC_2.2.5
100 clock_settime@@GLIBC_2.2.5
62 clock_getcpuclockid@@GLIBC_2.2.5
143 clock_nanosleep@@GLIBC_2.2.5
59 clock_gettime@@GLIBC_2.2.5

that's 439 bytes.  reading the disassembly, some funcs call calloc (which 
isn't a problem), but otherwise they're just syscall wrappers.

on 32bit systems, it's smaller (394).  these numbers might be slightly higher 
in practice due to alignment padding, but i think it's in the ballpark of 
irrelevant.

i'd wager optimizations used to compile glibc fluctuate more than what we're 
talking about here, and probably dwarfed when you look the optimized 
string/memory function variants.  so i wouldn't sweat this point.

>       that most applications do not need.

i've been seeing more apps over time start to use the clock_* symbols.  i 
don't have any data on this though.  just a "feel" :p.

>    b. For all configurations that exist today, we'll still need to have
>       clock_* symbols in librt.so because of existing binaries' symbol
>       version bindings.  With IFUNC we could do this in a way where
>       librt.so would not actually duplicate the code and would just resolve
>       those symbols using libc.so's definitions.  (But there are still some
>       machines where the tools don't support IFUNC at all.)

librt.so is linked against libc.so, so anything that is linked against those 
symbols should be able to find them automatically.  similarly, if someone were 
to dlopen(librt.so), the dlsym() will search the library's dependency tree 
(which libc.so is in), so it'd still be found.  what use case would 
necessitate keeping forwarding symbols in librt.so ?

worse comes to worse, we could leverage IFUNC when available and have fallback 
code to support targets that don't support IFUNC yet.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.