RE: Now I'm curious...
Hi, What could be done to improve the issues you mentioned? I guess nothing about atomic operations, but what about TLS? What linuxthreads restrictions are you aware of wrt arm7 or uclinux? Thanks in advance for any help. Cheers, Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Brook Sent: Wednesday, September 05, 2007 8:40 PM To: uclibc@uclibc.org Subject: Re: Now I'm curious... On Wednesday 05 September 2007, Daniel Jacobowitz wrote: > On Wed, Sep 05, 2007 at 11:49:12AM -0400, Crane, Matthew wrote: > > What makes you say it would be useless? Or that the performance will > > suck? > > I'm curious too. I wouldn't expect it to work without a bit of > hacking - I don't know if the futex and atomic bits in the kernel are > right for no-mmu, and the last time I checked the arm no-mmu port, > they weren't. But once that's solved, I would expect it to have the > same advantages on uClinux that it has on Linux. Last time I checked (a coupe of months ago) the futex bits should work, TLS worked by trapping and emulating a hardware register (very slow) and atomic operations weren't supported. So with current kernels it's accurate to say that ARM uClinux NPTL won't work, and even the bits that do work will be slow. However I'm fairly sure that all these problems are fixable. We needed significant kernel ABI enhancements to make NPTL work on normal linux, so it's reasonable to expect the same changes will be required for uClinux. Saying "use linuxthreads" is ok, if you ignore the fact that noone is really maintaining the linuxthreads code, it has some fairly fundamental restrictions, doesn't scale particularly well, and probably doesn't work on ARM SMP hardware. Paul ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: Now I'm curious...
Hi, It does build, whereas the linuxthreads fails with the sysdep-cancel.h not found. I haven't tested it yet though, I'm waiting for hw to arrive with more memory. What makes you say it would be useless? Or that the performance will suck? Besides some minor massaging, the only non-mmu issue in building it was the wrap of fork, which I changed to vfork. It was obvious it has not been tested with a non-mmu uclinux build though, as the sysnums to not generate correctly, and there is no handling of fork not being present. There is a set_tls syscall with arm no-mmu too, but I had to incorporate the __ARM_NR's into the gen sysnum script. Can you explain why linuxthreads performance be better? The reason wanted nptl is because it's supposedly a more efficient way to run threads on linux. Is that wrong? You didn't really give a specific reason why it wouldn't work. Matt -Original Message- From: Steven J. Hill [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 11:34 AM To: Crane, Matthew Cc: Steven J. Hill; uclibc@uclibc.org Subject: Re: Now I'm curious... > > Have you built nptl for arm7 no-mmu? I'm woried that I may be making > the effort to integrate it into our build for a big let down and > debugging effort in the end. > It will not work. Using NPTL on a no-MMU system is going to be pretty worthless IMHO. You should stick with linuxthreads. Not only does it make doing TLS difficult, the performance is going to suck. Also, the stuff from CodeSourcery will not support no-MMU. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
nptl arm patch + eabi
Hi, I'm using the uclibc 0.9.28 with the csl nptl patch, I'm building it with buildroot and a 2.6.22 uclinux kernel. The problem I'm having is the generated header ./include/bits/sysnum.h in uclibc does not include the EABI defines from the kernel header, or arm specific NR's that start with __ARM_NR. Where can I look to modify the generation of sysnum.h? Which makefile rules do this? Thanks for any help, Matt Error: libpthread/nptl/sysdeps/generic/libc-tls.c: In function '__libc_setup_tls': libpthread/nptl/sysdeps/generic/libc-tls.c:194: error: '__ARM_NR_set_tls' undeclared (first use in this function) libpthread/nptl/sysdeps/generic/libc-tls.c:194: error: (Each undeclared identifier is reported only once libpthread/nptl/sysdeps/generic/libc-tls.c:194: error: for each function it appears in.) make[1]: *** [libpthread/nptl/sysdeps/generic/libc-tls.o] Error 1 Additional changes required to build w uclinux for arm7 no mmu: - fstat64 not supported in sem_open.c, technically should be #ifdef'ed large file support. - unix_grantpt.c does not check if fork doesn't exist, removed prototype from top of file. - circular dependency in libpthread/nptl/sysdeps/unix/sysv/linux/arm/sysdep.h required moving include to before first #ifdef in order to pick up define for INTERNAL_SYSCALL ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: arm support for new linuxthreads in 0.9.29
Hi, You may need the nptl patch for the arm. http://www.busybox.net/lists/uclibc/2006-September/016535.html Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hamish Moffatt Sent: Tuesday, September 04, 2007 10:29 AM To: uclibc@uclibc.org Subject: arm support for new linuxthreads in 0.9.29 Hi, I'm trying to upgrade to 0.9.29 and use the new linuxthreads, but my target is arm and it won't compile due to missing sysdep-cancel.h. Attempts to drop in versions thereof from glibc's code result in successful compilation, but any threaded application segfaults during startup. Switching back to the old linuxthreads works, but I'm having problems with a multithreaded application hanging so I want to try the new library... What do I need to do to get the new version to compile? thanks Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Nptl and arm7
Hi, I am using a uclinux 2.6 kernel and the latest uclibc on an atmel at91x40 type cpu. I'm having issues getting around the lack of a sysdep-cancel for arm. Is the nptl branch of uclibc reasonably stable? Has anybody run this on an arm7? Thanks, Matt ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
