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