ARM NPTL support for uClibc
Peter S. Mazinger
ps.m at gmx.net
Sat Aug 12 21:45:28 UTC 2006
On Fri, 11 Aug 2006, Jim Blandy wrote:
>
> Hi, folks. Building on Steve Hill's work, CodeSourcery has put
> together a uClibc NPTL port for the ARM processor we'd like to
> contribute. Our patch is relative to today's uClibc trunk. This work
> was done for MontaVista.
>
> We've tested it configured for EABI ARM with no threads, using
> linuxthreads.old, and using NPTL (libpthread/linuxthreads doesn't
> support ARM), with no regressions. There is one test suite regression
> relative to the GNU C library, which hopefully I'll get fixed very
> shortly. I've included more detailed results below.
>
> It's a very large patch --- 3MB including the new trees, or 633kB with
> the new directories omitted (libpthread/nptl, libpthread/nptl_db,
> test/nptl, and test/tls). There are changes throughout the uClibc
> tree. The patch is available at the following URL:
>
> http://www.codesourcery.com/public/uClibc-0.9.28-csl-nptl-4.patch.gz
Nice work, congratulation...
Some early comments:
netdb.h: libc_hidden_proto(__h_errno_location) will only work with NPTL,
maybe if new linuxthreads will use TLS, but does not work with
linuxthreads_old and linuxthreads without TLS for sure
tls.h: I would create an include/tls.h file that is includeable always and
depending on config options does what it has to do, include the arch
specific tls.h or do some defines. This way linuxthreads can benefit of
it in the future as well and all the guards when it is included can go
away (same could go for not-cancel.h/sysdep-cancel.h and do the #define
close_not_cancel_no_status close in include/not-cancel.h, including then
some arch specific from here if needed, these defines could also go into
libc-internal.h)
Please review all the use of __UCLIBC_HAS_THREADS_NATIVE__ if they are not
really USE_TLS or __UCLIBC_USE_TLS__ (not present yet, could be a config
option enforced for NPTL and optional for new linuxthreads) ex. __res_state
generally for __x() prototypes: the headers in include/* are not like
those in glibc, glibc has in include/* those headers that are only
internally used to build glibc. uClibc provides here the later
visible/installed headers.
sched.h: please don't pollute with __clone[2] the visible header, maybe
move those into bits/uClibc_sched.h and include it guarded or guard it by
at least ifdef _LIBC (wondering why you needed to rename clone() to
__clone() for arm)
time.h: same for the define
unistd.h: same for __exit_thread
remove tls.h/stdio-lock.h on install
libc_hidden_proto(res_init) needs to go as well, but if you decided to
change hidden_proto/def(res_init) combo to attribute_hidden/strong_alias,
then you also need to provide the prototype for __res_init_internal.
the change in libc/Makefile.in is wrong:
if you intend to add files to both libc.a and libc.so then you can do:
libc-y += file.o in libpthread/nptl/Makefile.in,
else you add it to libc-static-y or libc-shared-y (libc-a-y/libc-so-y
should be used only in this file, I hope at least)
despite the fact that uClibc-svn has
libc_hidden_errno/libc_hidden_def(errno/h_errno) I did some tests and it
seems that it is not OK (maybe it is only usable if TLS is also used,
although your changes/comment suggests you had the same results)
mmap.c: please add libc_hidden_proto(mmap64). mmap64() can only
be used if LFS is enabled, please provide fallback for non-LFS
Cosmetics:
shortcut for __attribute__ ((tls_model ("initial-exec"))) is
attribute_tls_model_ie already, use that over all place (but not in
visible parts of visible headers)
SINGLE_THREAD_P put into some generic place (libc-internal.h)
this looks (almost) always the same:
/* was __UCLIBC_HAS_THREADS_NATIVE__ */
/* should go into a common header */
#if defined __UCLIBC_USE_THREADS__ && !defined __LINUXTHREADS_OLD__
# include <sysdep-cancel.h> /* provide generic sysdep-cancel.h in include/
* that is removed after install and put the
* SINGLE_THREAD_P there */
#else
# define SINGLE_THREAD_P 1
#endif
/* has a similar macro in wrapsyscall.c */
if (SINGLE_THREAD_P)
return some_func(...);
#if defined __UCLIBC_USE_THREADS__ && !defined __LINUXTHREADS_OLD__
int oldtype = LIBC_CANCEL_ASYNC ();
some_type result = some_func(...);
LIBC_CANCEL_RESET ();
return result;
#endif
Does SINGLE_THREAD_P 1 mean only NPTL, or it could be linuxthreads
(probably only new) as well? Is it TLS dependent or not?
Out of curiosity, which tst-cancel4.c tests from glibc does it not pass
(the test was not provided in the patch)?
Thanks, 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