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