cancellation variant for uClibc?

Peter S. Mazinger ps.m at gmx.net
Fri Aug 25 14:19:26 UTC 2006


On Fri, 25 Aug 2006, Carmelo AMOROSO wrote:

> Carmelo AMOROSO wrote:
> 
> > Peter S. Mazinger wrote:
> >
> >>On Thu, 24 Aug 2006, Carmelo AMOROSO wrote:
> >>
> >>  
> >>
> >>>Yes, this is one of the main question I was going to ask to Steve, 
> >>>before starting to merge his code with mine
> >>>(I mean the uClibc-nptl port for SuperH at STMicro)
> >>>
> >>>    
> >>>
> >>>>For the Arm port we added the cancellation code (with appropriate macros) 
> >>>>directly into the existing implementations.
> >>>> 
> >>>>
> >>>>      
> >>>>
> >>>This is the same approach we used, so if you don't use the NPTL pthread 
> >>>implementation, the __libc_XXX functions
> >>>will be not cancellable. And we have only one implementation into libc.
> >>>    
> >>>
> >>
> >>Then I would propose to do that for all threads variants, get rid of the 
> >>__libc_x versions, no need for wrapsyscall.c in linuxthreads_old
> >>
> >>Consider though to replace all the similar code starting with
> >>if (SINGLE_THREAD_P)
> >>	...
> >>with a macro like in wrapsyscall.c (I have proposed this when I commented 
> >>on the arm port already)
> >>
> >>
> >>  
> >>
> > Well, it could be a good choice, so no needs to changes the __libc_x 
> > from linux/common directory.
> > We need an agreement among different ports... I'd like to hear from 
> > Steve, because is approach is very
> > different.
> 
> Sorry, the previous mail was not complete; I sent it erroneously.
> 
> One thing is not yet clear to me (sorry for that).
> What is the policy for uClibc regarding some system functions (open, 
> read and so on) ?

No real policy, linuxthread.old is the implementation from an old glibc
NPTL is the "new way" in glibc

> If I look at the symbol table of the libuClibc-0.9.28 (SH port, 
> linuxthreads old), I can see that
> we have a GLOBAL symbol __libc_open and a WEAK open; while in the 
> libpthread-0.9.28
> there is an UND __libc_open (so it will be bound to the libc's one)... 
> right?

__libc_open() is an uncancellable open() in libc (as is open in libc), 
and it is exported to add a cancellable open() version to libpthread by 
wrapsyscalls.c

If we put cancellable open() into libc and no open() in libpthread, 
__libc_open can be removed (glibc keeps all functions ever provided, even 
if not needed anymore)

> Looking at glibc-2.4 (SH, NPTL), I found the following scenario:
> __libc_open is LOCAL to libc.so.6
> open / __open are WEAK alias for __libc_open.
> The same for the libpthread.
> 
> With the introduction of NPTL into uClibc, how this will change, if it will?
> If I understood what Peter is suggesting, we should have:
> 
> __libc_open defined as GLOBAL into libc.so.0 (not cancellable) + open as 
> weak alias
>  open (cancellable) as GLOBAL into libpthread (and __libc_open an UND 
> symbol).

no, __libc_open removed, open() cancellable in libc (for internal use of a 
non cancellable open() you provide already open_nocancel() iirc)
this will work with both nptl and new linuxthreads, but not with 
linuxthreads.old (LT old lacks support for header.multiple_threads 
in some structure iirc, needed to define SINGLE_THREAD_P, so some other 
alternative would be needed). 
Alternatively we can keep
lt_strong_alias(open,__libc_open)
where
#ifdef LINUXTHREADS_OLD
#define SINGLE_THREAD_P 1
#define lt_strong_alias(x,y) strong_alias(x,y)
#else
#define lt_strong_alias(x,y)
#endif
and make use of the cancellation wrapper in old LT

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