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

Joakim Tjernlund joakim.tjernlund at transmode.se
Sun Dec 11 14:29:12 UTC 2005


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




More information about the uClibc mailing list