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

[Peter S. Mazinger]

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?

Peter
> 
> > 
> > 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?
> 
> 
> 

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