Comment on 'libc/signal/sigwait.c'.

Joakim Tjernlund joakim.tjernlund at transmode.se
Sat Dec 10 23:09:35 UTC 2005


> 
> On Sat, 10 Dec 2005, Peter S. Mazinger wrote:
> 
> > On Sat, 10 Dec 2005, Steven J. Hill wrote:
> > 
> > > Peter,
> > > 
> > > Would you object loudly if I removed the '#define 
> sigwaitinfo __sigwaitinfo'
> > > from this file? We again have a NPTL version of 
> '__sigwaitinfo' that 
> > > you can look at in 
> > > 'libpthread/nptl/sysdeps/unix/sysv/linux/sigwaitinfo.c'. 
> When we go to use libpthreads, it would not use the correct 
> function. Thanks.
> > > 
> > > -Steve
> > 
> > Well, yes ;-)
> > 
> > We need some solution to this generally.
> > 
> > What about:
> > 1. define __libc_X in libc
> > 2. define hidden_weak_alias(__libc_X,__X) 3. provide 
> weak_alias(__X,X) 
> > for external apps within libc 4. use within libc __X 
> exclusively, we 
> > need to use a hidden version to get
> > 	rid of the relocations (maybe one correctly, not with 
> the define X 
> > 	__X hack)
> > 5. define __X in libpthreads (no weak), this will overwrite 
> the hidden 
> > weak __X in libc (I hope) 6. strong_alias(__X,X) in libpthreads
> > 
> > If an app external app does not use threads, it references X, (and 
> > will use __X from libc and finally __libc_X), else if it uses 
> > pthreads, using X gets the __X from libpthreads and that overwrites 
> > the weak __X in libc (again I hope this). I am not sure (Jocke 
> > either), if the hidden weak in libc can be overwritten by a 
> strong one 
> > in libpthread
> 
> maybe it would work w/o __libc_X as well (some of glibc's files do it)
> 
> 1. __X hidden in libc
> 2. weak_alias(__X,X)
> 3. __X hidden in libpthread
> 4. X strong_alias(__X,X)

That will only work if pthread is loaded before libc. If a lib uses pthreads internally
and the app doesn't, it will fail.

The relocation process will use the first defined symbol it finds, doesn't matter
it its weak or strong as long its value is nonzero. 

> 
> external apps will catch the correct one (they only use X), 
> so if they link against libpthread, they will use it's 
> version, else the libc one What happens though if libpthread 
> has to overwrite the function in libc?
> Are the 2 hidden versions capable of this?





More information about the uClibc mailing list