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