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

Peter S. Mazinger ps.m at gmx.net
Sun Dec 11 14:59:50 UTC 2005


On Sun, 11 Dec 2005, Joakim Tjernlund wrote:

>  
> > 
> > On Sun, 11 Dec 2005, Joakim Tjernlund wrote:
> > 
> > > > 
> > > > 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.
> > 
> > this means that the first proposal will fail too?
> 
> I think so, a hidden fun cannot be premepted. To preempt/overwrite a function
> at runtime it must have a reloc.
> 
> I think we have 3 options
> 
> 1) see, http://uclibc.org/lists/uclibc/2005-December/013471.html
> 
> 2) restore the old weaks.c and let a few libs break.
> 
> 3) fix the libs to do something like this:
>    extern int weak pthread_mutex_init();
> 
>    if (pthread_mutex_init != NULL)
>         pthread_mutex_init();
>  
> I don't know what glibc does, anyone figured that out?

Jocke, we are not speaking of the weaks.c, the affected ones are [__]sig*

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list