From rob at landley.net Tue May 1 10:42:23 2007 From: rob at landley.net (Rob Landley) Date: Tue, 1 May 2007 13:42:23 -0400 Subject: POSIX: threads (pthreads) & message queues In-Reply-To: <200704301724.22375.vapier@gentoo.org> References: <46348E4A.9080005@gmx.de> <200704301724.22375.vapier@gentoo.org> Message-ID: <200705011342.23847.rob@landley.net> On Monday 30 April 2007 5:24 pm, Mike Frysinger wrote: > On Sunday 29 April 2007, Martin Kuner wrote: > > Does the uClib supports POSIX threads (NPTL) > > it supports LinuxThreads which is mostly POSIX compliant ... NPTL is being > worked on Query, should LINUXTHREADS_OLD be hardwired to y and the config option removed for the 0.9.29 release, since the non-old version doesn't actually seem to work right now? I know 0.9.30 is going to make huge changes in this space, I'm just talking about 0.9.29... Rob From vapier at gentoo.org Wed May 2 01:07:51 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 2 May 2007 04:07:51 -0400 Subject: tst-too-many-cleanups never completes In-Reply-To: <20070419195735.GA17075@caradoc.them.org> References: <20070416214726.GA16829@caradoc.them.org> <200704162114.37811.vapier@gentoo.org> <20070419195735.GA17075@caradoc.them.org> Message-ID: <200705020407.52142.vapier@gentoo.org> On Thursday 19 April 2007, Daniel Jacobowitz wrote: > On Mon, Apr 16, 2007 at 09:14:37PM -0400, Mike Frysinger wrote: > > On Monday 16 April 2007, Daniel Jacobowitz wrote: > > > - It calls sleep expecting a cancellation point at nanosleep. But > > > libc.so's sleep.c has "libc_hidden_proto(nanosleep)" which means it > > > always calls the libc.so version, never the wrapped version in > > > libpthread.so that's a cancellation point. Delete that line from > > > sleep.c and usleep.c and now sleep/usleep start acting like > > > cancellation points. > > > > i need to finish up my local cancellation handler rewrite and get it > > merged ... > > In case anyone's interested in a fix for this meanwhile: > > --- > libc/unistd/sleep.c | 1 - > libc/unistd/usleep.c | 2 -- > 2 files changed, 3 deletions(-) merged, cheers -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070502/e57137d1/attachment.pgp From vapier at gentoo.org Wed May 2 01:08:43 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 2 May 2007 04:08:43 -0400 Subject: [PATCH] Use pid_t for passing PID values in tcgetpgrp In-Reply-To: <12b5f1ef0704301442n7b60cc9ewea68e4bc781b02b@mail.gmail.com> References: <12b5f1ef0704222010j7e6cbc3bxcb974fc1400c6b0@mail.gmail.com> <200704301719.51543.vapier@gentoo.org> <12b5f1ef0704301442n7b60cc9ewea68e4bc781b02b@mail.gmail.com> Message-ID: <200705020408.44079.vapier@gentoo.org> On Monday 30 April 2007, Nickolai Zeldovich wrote: > On 4/30/07, Mike Frysinger wrote: > > gmail attaches files just fine > > Sure, patch is attached. merged, cheers > (I'd thought attachments to be more annoying than URLs.) usually quite the opposite in the open source world -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070502/e0be332c/attachment.pgp From vapier at gentoo.org Wed May 2 01:09:36 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 2 May 2007 04:09:36 -0400 Subject: [PATCH] Avoid near-infinite looping in __gen_tempname In-Reply-To: <12b5f1ef0704301443h5decb4etaa776799dfab854e@mail.gmail.com> References: <12b5f1ef0704222014q7839eac8v42c2d4e59a9fb92c@mail.gmail.com> <200704301719.33922.vapier@gentoo.org> <12b5f1ef0704301443h5decb4etaa776799dfab854e@mail.gmail.com> Message-ID: <200705020409.36847.vapier@gentoo.org> On Monday 30 April 2007, Nickolai Zeldovich wrote: > On 4/30/07, Mike Frysinger wrote: > > On Sunday 22 April 2007, Nickolai Zeldovich wrote: > > > The code to create a unique file (mktemp) has a logic error in uClibc. > > > When __gen_tempname picks a file name that already exists, the code > > > attempts to retry. However, the code to pick a new file name is > > > outside of this retry loop, causing a retry with the same exact > > > filename, which is very likely to fail again. This patch fixes this > > > problem by moving the random filename generation code inside the retry > > > loop: > > > > so attach your patch since the URL here is unavailable > > Patch attached. erm that's no good ... you've got a nested for loop and they both use the variable "i" ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070502/ac661b98/attachment.pgp From nickolai at cs.stanford.edu Wed May 2 10:15:49 2007 From: nickolai at cs.stanford.edu (Nickolai Zeldovich) Date: Wed, 2 May 2007 10:15:49 -0700 Subject: [PATCH] Avoid near-infinite looping in __gen_tempname In-Reply-To: <200705020409.36847.vapier@gentoo.org> References: <12b5f1ef0704222014q7839eac8v42c2d4e59a9fb92c@mail.gmail.com> <200704301719.33922.vapier@gentoo.org> <12b5f1ef0704301443h5decb4etaa776799dfab854e@mail.gmail.com> <200705020409.36847.vapier@gentoo.org> Message-ID: <12b5f1ef0705021015l43fed9acq8704dcc4f5ad0905@mail.gmail.com> Oops, I mis-merged with 0.9.29-rc1.. The outer variable used to be called "count" in 0.9.28. Attached is the fixed version. Nickolai. On 5/2/07, Mike Frysinger wrote: > On Monday 30 April 2007, Nickolai Zeldovich wrote: > > On 4/30/07, Mike Frysinger wrote: > > > On Sunday 22 April 2007, Nickolai Zeldovich wrote: > > > > The code to create a unique file (mktemp) has a logic error in uClibc. > > > > When __gen_tempname picks a file name that already exists, the code > > > > attempts to retry. However, the code to pick a new file name is > > > > outside of this retry loop, causing a retry with the same exact > > > > filename, which is very likely to fail again. This patch fixes this > > > > problem by moving the random filename generation code inside the retry > > > > loop: > > > > > > so attach your patch since the URL here is unavailable > > > > Patch attached. > > erm that's no good ... you've got a nested for loop and they both use the > variable "i" ... > -mike > > -------------- next part -------------- A non-text attachment was scrubbed... Name: uclibc-tempname2.patch Type: application/octet-stream Size: 1031 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20070502/a5bdc864/attachment.obj From nickolai at cs.stanford.edu Wed May 2 13:27:21 2007 From: nickolai at cs.stanford.edu (Nickolai Zeldovich) Date: Wed, 2 May 2007 13:27:21 -0700 Subject: [PATCH] Avoid near-infinite looping in __gen_tempname In-Reply-To: <12b5f1ef0705021015l43fed9acq8704dcc4f5ad0905@mail.gmail.com> References: <12b5f1ef0704222014q7839eac8v42c2d4e59a9fb92c@mail.gmail.com> <200704301719.33922.vapier@gentoo.org> <12b5f1ef0704301443h5decb4etaa776799dfab854e@mail.gmail.com> <200705020409.36847.vapier@gentoo.org> <12b5f1ef0705021015l43fed9acq8704dcc4f5ad0905@mail.gmail.com> Message-ID: <12b5f1ef0705021327x31fcf4c1we7f9e63a5fb50b3a@mail.gmail.com> Having a bad patch day apparently. Attached is a version that compiles. Nickolai. -------------- next part -------------- A non-text attachment was scrubbed... Name: uclibc-tempname3.patch Type: application/octet-stream Size: 1266 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20070502/647d3ff2/attachment.obj From ehuang at ix.netcom.com Wed May 2 22:09:27 2007 From: ehuang at ix.netcom.com (ehuang at ix.netcom.com) Date: Thu, 3 May 2007 01:09:27 -0400 (EDT) Subject: What is XMALLOC and how it compares with malloc? Message-ID: <10587423.1178168967698.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> I can not find anything to explain what is xmalloc with respect to uClibc other than a few cvs checks and diffs. I'm getting seg faults whenever doing malloc/xmalloc on an application compiled using ARM & uclib which otherwise works perfectly on regular Linux (glibc) Browsing the source (Very nice!) only found source code for MALLOC thanks in advance From vapier at gentoo.org Wed May 2 22:47:33 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 3 May 2007 01:47:33 -0400 Subject: What is XMALLOC and how it compares with malloc? In-Reply-To: <10587423.1178168967698.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> References: <10587423.1178168967698.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Message-ID: <200705030147.34159.vapier@gentoo.org> On Thursday 03 May 2007, ehuang at ix.netcom.com wrote: > I can not find anything to explain what is xmalloc with respect to uClibc > other than a few cvs checks and diffs. you're going to have to be a little bit more clear as to what you're referring to when you say "xmalloc" ... there is no such thing in uClibc xmalloc() is typically an application specific thing that wraps the call to malloc() to make sure it succeeded so that the return checks dont need to be duplicated everywhere else -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070503/a258bd62/attachment.pgp From ehuang at ix.netcom.com Thu May 3 12:42:03 2007 From: ehuang at ix.netcom.com (ehuang at ix.netcom.com) Date: Thu, 3 May 2007 15:42:03 -0400 (EDT) Subject: What is XMALLOC and how it compares with malloc? Message-ID: <19236584.1178221323743.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Dear Mike, thanks for quickly getting back to me. The application is RDESKTOP. It has mess of both malloc and xmalloc. Runs fine on Fedora Core (presumely glibc) but get segfaults under Cirrus ARM linux which uses libcClibc-0.9.28.so So, I'm trying to understand and trace the memory management. Whats frustrating is not finding any decent explanation thru google about XMALLOC. Not even wikipedia! GREP MALLOC cache.c: text->data = xmalloc(length); nwin.c: uint8 *d2 = xmalloc(width * height); nwin.c: uint8 *d2 = xmalloc(width * height * (depth / 8)); nwin.c: bmp = (GR_IMAGE_HDR*)malloc(sizeof(GR_IMAGE_HDR)); nwin.c: bmp->palette = (MWPALENTRY*)malloc(2 * sizeof(MWPALENTRY)); nwin.c: bmp->imagebits = (MWUCHAR*)malloc(datasize); nwin.c:STATUS("doing malloc - sizeof %d\n",sizeof(GR_PALETTE) ); nwin.c: pal = (GR_PALETTE*)malloc(sizeof(GR_PALETTE)); nwin.c: STATUS("malloc error!\n"); nwin.c: pixels = (GR_PIXELVAL*)malloc(cx * cy * depth); orders.c: d2 = xmalloc(width*height); orders.c: bmpdata = xmalloc(width * height); orders.c: map.colours = xmalloc(3 * map.ncolours); orders.c: rev_data = xmalloc(datasize); rdesktop.c:#include /* malloc realloc free */ rdesktop.c: char *errormsg = (char *)malloc(500); rdesktop.c:/* malloc; exit if out of memory */ rdesktop.c:void *xmalloc2(int l, char *s, int size) rdesktop.c: void *mem = malloc(size); rdesktop.c: ERROR("xmalloc %d\n", size); rdesktop.c:/* malloc; exit if out of memory */ rdesktop.c:void *xmalloc(int size) rdesktop.c: void *mem = malloc(size); rdesktop.c: ERROR("xmalloc %d\n", size); rdp.c: rawdata = xmalloc(width * height); rdp.c: rawdata = xmalloc(width * height); secure.c: mcs_data.p = mcs_data.data = xmalloc(mcs_data.size); tcp.c: in.data = xmalloc(in.size); tcp.c: out.data = xmalloc(out.size); -----Original Message----- >From: Mike Frysinger >Sent: May 3, 2007 1:47 AM >To: uclibc at uclibc.org, ehuang at ix.netcom.com >Subject: Re: What is XMALLOC and how it compares with malloc? > >On Thursday 03 May 2007, ehuang at ix.netcom.com wrote: >> I can not find anything to explain what is xmalloc with respect to uClibc >> other than a few cvs checks and diffs. > >you're going to have to be a little bit more clear as to what you're referring >to when you say "xmalloc" ... there is no such thing in uClibc > >xmalloc() is typically an application specific thing that wraps the call to >malloc() to make sure it succeeded so that the return checks dont need to be >duplicated everywhere else >-mike From ddaney at avtrex.com Thu May 3 12:48:10 2007 From: ddaney at avtrex.com (David Daney) Date: Thu, 03 May 2007 12:48:10 -0700 Subject: What is XMALLOC and how it compares with malloc? In-Reply-To: <19236584.1178221323743.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> References: <19236584.1178221323743.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Message-ID: <463A3C7A.5090008@avtrex.com> ehuang at ix.netcom.com wrote: > Dear Mike, > > thanks for quickly getting back to me. > > The application is RDESKTOP. It has mess of both malloc and xmalloc. > Runs fine on Fedora Core (presumely glibc) but get segfaults under Cirrus ARM > linux which uses libcClibc-0.9.28.so So, I'm trying to understand and > trace the memory management. Whats frustrating is not finding any decent > explanation thru google about XMALLOC. Not even wikipedia! > Wow, not even in wikipedia?! Have you tried looking at the source code of the function? According to your grep, you should be able to find it in rdesktop.c. David Daney > > GREP MALLOC > > cache.c: text->data = xmalloc(length); > nwin.c: uint8 *d2 = xmalloc(width * height); > nwin.c: uint8 *d2 = xmalloc(width * height * (depth / 8)); > nwin.c: bmp = (GR_IMAGE_HDR*)malloc(sizeof(GR_IMAGE_HDR)); > nwin.c: bmp->palette = (MWPALENTRY*)malloc(2 * sizeof(MWPALENTRY)); > nwin.c: bmp->imagebits = (MWUCHAR*)malloc(datasize); > nwin.c:STATUS("doing malloc - sizeof %d\n",sizeof(GR_PALETTE) ); > nwin.c: pal = (GR_PALETTE*)malloc(sizeof(GR_PALETTE)); > nwin.c: STATUS("malloc error!\n"); > nwin.c: pixels = (GR_PIXELVAL*)malloc(cx * cy * depth); > orders.c: d2 = xmalloc(width*height); > orders.c: bmpdata = xmalloc(width * height); > orders.c: map.colours = xmalloc(3 * map.ncolours); > orders.c: rev_data = xmalloc(datasize); > rdesktop.c:#include /* malloc realloc free */ > rdesktop.c: char *errormsg = (char *)malloc(500); > rdesktop.c:/* malloc; exit if out of memory */ > rdesktop.c:void *xmalloc2(int l, char *s, int size) > rdesktop.c: void *mem = malloc(size); > rdesktop.c: ERROR("xmalloc %d\n", size); > rdesktop.c:/* malloc; exit if out of memory */ > rdesktop.c:void *xmalloc(int size) > rdesktop.c: void *mem = malloc(size); > rdesktop.c: ERROR("xmalloc %d\n", size); > rdp.c: rawdata = xmalloc(width * height); > rdp.c: rawdata = xmalloc(width * height); > secure.c: mcs_data.p = mcs_data.data = xmalloc(mcs_data.size); > tcp.c: in.data = xmalloc(in.size); > tcp.c: out.data = xmalloc(out.size); > From rob at landley.net Thu May 3 14:54:08 2007 From: rob at landley.net (Rob Landley) Date: Thu, 3 May 2007 17:54:08 -0400 Subject: What is XMALLOC and how it compares with malloc? In-Reply-To: <19236584.1178221323743.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> References: <19236584.1178221323743.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Message-ID: <200705031754.08449.rob@landley.net> On Thursday 03 May 2007 3:42 pm, ehuang at ix.netcom.com wrote: > rdesktop.c:/* malloc; exit if out of memory */ > rdesktop.c:void *xmalloc(int size) Note that the reason this is so common is that malloc returning nonzero doesn't tell you a darn thing about whether or not the allocation actually succeeded on any modern system with virtual memory. What malloc does is allocates virtual memory and populates it with duplicate copy-on-write mappings of the zero page. Attempts to actually write to it break the COW and allocate physical pages, so the malloc is only going to return NULL if it ran out of _virtual_ memory (which happens on 32-bit systems, but is much less common and not really something you can do anything useful about). When the system truly runs out of memory first it'll swap thrash for a bit (true even if you have no swap file, because mmap()ed files can flush the file contents back to disk to free up the physical pages and both executables and shared libraries are mmap()ed, and then it'll either trigger the out of memory killer. (If you've disabled the OOM killer it'll instead freeze the entire system solid, which some people do because they think that hanging the entire system is an improvement over killing individual processes in an emergency because killing processes is bad, m'kay.) So the actual physical allocation happens when writing to memory, not via malloc(), and the OOM killer steps in and goes "bang" rather than giving you ar eturn value you can check. Which causes the same sort of exit() that xmalloc() would. Rob From thekevinday at gmail.com Thu May 3 15:04:36 2007 From: thekevinday at gmail.com (Kevin Day) Date: Thu, 3 May 2007 16:04:36 -0600 Subject: What is XMALLOC and how it compares with malloc? In-Reply-To: <463A3C7A.5090008@avtrex.com> References: <19236584.1178221323743.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <463A3C7A.5090008@avtrex.com> Message-ID: On 5/3/07, David Daney wrote: > ehuang at ix.netcom.com wrote: > > Dear Mike, > > > > thanks for quickly getting back to me. > > > > The application is RDESKTOP. It has mess of both malloc and xmalloc. > > Runs fine on Fedora Core (presumely glibc) but get segfaults under Cirrus ARM > > linux which uses libcClibc-0.9.28.so So, I'm trying to understand and > > trace the memory management. Whats frustrating is not finding any decent > > explanation thru google about XMALLOC. Not even wikipedia! > > > > Wow, not even in wikipedia?! Have you tried looking at the source code > of the function? > > According to your grep, you should be able to find it in rdesktop.c. > > David Daney > > > > > GREP MALLOC > > > > cache.c: text->data = xmalloc(length); > > nwin.c: uint8 *d2 = xmalloc(width * height); > > nwin.c: uint8 *d2 = xmalloc(width * height * (depth / 8)); > > nwin.c: bmp = (GR_IMAGE_HDR*)malloc(sizeof(GR_IMAGE_HDR)); > > nwin.c: bmp->palette = (MWPALENTRY*)malloc(2 * sizeof(MWPALENTRY)); > > nwin.c: bmp->imagebits = (MWUCHAR*)malloc(datasize); > > nwin.c:STATUS("doing malloc - sizeof %d\n",sizeof(GR_PALETTE) ); > > nwin.c: pal = (GR_PALETTE*)malloc(sizeof(GR_PALETTE)); > > nwin.c: STATUS("malloc error!\n"); > > nwin.c: pixels = (GR_PIXELVAL*)malloc(cx * cy * depth); > > orders.c: d2 = xmalloc(width*height); > > orders.c: bmpdata = xmalloc(width * height); > > orders.c: map.colours = xmalloc(3 * map.ncolours); > > orders.c: rev_data = xmalloc(datasize); > > rdesktop.c:#include /* malloc realloc free */ > > rdesktop.c: char *errormsg = (char *)malloc(500); > > rdesktop.c:/* malloc; exit if out of memory */ > > rdesktop.c:void *xmalloc2(int l, char *s, int size) > > rdesktop.c: void *mem = malloc(size); > > rdesktop.c: ERROR("xmalloc %d\n", size); > > rdesktop.c:/* malloc; exit if out of memory */ > > rdesktop.c:void *xmalloc(int size) > > rdesktop.c: void *mem = malloc(size); > > rdesktop.c: ERROR("xmalloc %d\n", size); > > rdp.c: rawdata = xmalloc(width * height); > > rdp.c: rawdata = xmalloc(width * height); > > secure.c: mcs_data.p = mcs_data.data = xmalloc(mcs_data.size); > > tcp.c: in.data = xmalloc(in.size); > > tcp.c: out.data = xmalloc(out.size); > > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > perhaps xmalloc is akin to the rpl_malloc issues that autoconf imposes when malloc does not return the unsafe glibc live pointer. however, looking into this myself, the link http://gcc.gnu.org/ml/gcc-patches/1999-11/msg00025.html refers to xmalloc as coming from gcc My next assumption is that xmalloc is some sort of gcc's internal implementation of malloc This suggests that the rdesktop program is commiting malpractice of calling internal gcc functions and no the standard (and by now probably universal) malloc. however, considering the application name 'rdesktop' it reminds me of remote_desktop which ulitmately references Xorg. I faintly and possibly imaginarily remember seeing xmalloc during Xorg compilation. This seems to make more sense than the my gcc assumption above, so I feel safest to assume that it is calling Xorg's malloc implementation for some reason. Which seems to explain why it is called "xmalloc" for Xorg Malloc.. So, there was my entire sequence of thoughts regardding your issue, I say look into Xorg and find xmalloc. -- Kevin Day From drow at false.org Thu May 3 20:12:12 2007 From: drow at false.org (Daniel Jacobowitz) Date: Thu, 3 May 2007 23:12:12 -0400 Subject: What is XMALLOC and how it compares with malloc? In-Reply-To: References: <19236584.1178221323743.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <463A3C7A.5090008@avtrex.com> Message-ID: <20070504031212.GA23461@caradoc.them.org> On Thu, May 03, 2007 at 04:04:36PM -0600, Kevin Day wrote: > > > rdesktop.c:/* malloc; exit if out of memory */ > > > rdesktop.c:void *xmalloc(int size) > My next assumption is that xmalloc is some sort of gcc's internal > implementation of malloc Your assumption is completely wrong. > This seems to make more sense than the my gcc assumption above, so I > feel safest to assume that it is calling Xorg's malloc implementation > for some reason. Which seems to explain why it is called "xmalloc" for > Xorg Malloc.. This one too. As David already said, it's a common name for a common purpose. rdesktop has its own. Can we please stop speculating without evidence, now? -- Daniel Jacobowitz CodeSourcery From Harald.Krammer at hkr.at Fri May 4 01:21:03 2007 From: Harald.Krammer at hkr.at (Harald Krammer) Date: Fri, 4 May 2007 10:21:03 +0200 (CEST) Subject: ld preload and threads Message-ID: <37224.80.120.2.52.1178266863.squirrel@secure.proserver1.at> Hi! I have a question about LD_PRELOAD. Is it possible to use pthread functions for preloaded libs or exists any restriction for that? Currently I got few strange problems when I use pthread functions in preloaded libs. (seg faults) At the moment I can't find the location for it, because the stack seems invalid. If I enable debugging support in uclibc then I get an additional problems like process do exit when a thread finish. The preload-lib-concept is working under glibc, but it isn't comparable, because under glibc I am using a different thread model (NPTL) instead of LinuxThreads. Under glibc I played also with LD_ASSUME_KERNEL but without any effects - it is always working. Version: 0.9.28.3 Buildroot-GCC 3.4.6 with softfloat Linux ARM926-Core Kernel: 2.6.20 A 2 week old snapshot of current version (0.9.29) looks total similar. Any hints are welcome. Nice greetings, Harald -- Harald Krammer Brucknerstrasse 33 A - 4020 Linz AUSTRIA Mobil +43.(0) 664. 130 59 58 Mail: Harald.Krammer (at) hkr.at From Harald.Krammer at hkr.at Thu May 3 14:08:40 2007 From: Harald.Krammer at hkr.at (Harald Krammer) Date: Thu, 03 May 2007 23:08:40 +0200 Subject: ld preload and threads Message-ID: <463A4F58.2060107@hkr.at> Hi! I have a question about LD_PRELOAD. Is it possible to use pthread functions for preloaded libs or exists any restriction for that? Currently I got few strange problems when I use pthread functions in preloaded libs. (seg faults) At the moment I can't find the location for it, because the stack seems invalid. If I enable debugging support in uclibc then I get an additional problems like process do exit when a thread finish. The preload-lib-concept is working under glibc, but it isn't comparable, because under glibc I am using a different thread model (NPTL) instead of LinuxThreads. Under glibc I played also with LD_ASSUME_KERNEL but without any effects - it is always working. Version: 0.9.28.3 Buildroot-GCC 3.4.6 with softfloat Linux ARM926-Core Kernel: 2.6.20 A 2 week old snapshot of current version (0.9.29) looks total similar. Any hints are welcome. Nice greetings, Harald -- Harald Krammer Brucknerstrasse 33 A - 4020 Linz AUSTRIA Mobil +43.(0) 664. 130 59 58 Mail: Harald.Krammer (at) hkr.at From vapier at gentoo.org Sun May 6 02:13:39 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 May 2007 05:13:39 -0400 Subject: ld preload and threads In-Reply-To: <463A4F58.2060107@hkr.at> References: <463A4F58.2060107@hkr.at> Message-ID: <200705060513.40515.vapier@gentoo.org> On Thursday 03 May 2007, Harald Krammer wrote: > I have a question about LD_PRELOAD. Is it possible to use pthread > functions for preloaded libs or exists any restriction for that? there should be no such restriction on libraries with LD_PRELOAD -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070506/3ba3ed1b/attachment.pgp From vapier at gentoo.org Sun May 6 02:19:13 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 May 2007 05:19:13 -0400 Subject: [PATCH] Avoid near-infinite looping in __gen_tempname In-Reply-To: <12b5f1ef0705021327x31fcf4c1we7f9e63a5fb50b3a@mail.gmail.com> References: <12b5f1ef0704222014q7839eac8v42c2d4e59a9fb92c@mail.gmail.com> <12b5f1ef0705021015l43fed9acq8704dcc4f5ad0905@mail.gmail.com> <12b5f1ef0705021327x31fcf4c1we7f9e63a5fb50b3a@mail.gmail.com> Message-ID: <200705060519.14486.vapier@gentoo.org> On Wednesday 02 May 2007, Nickolai Zeldovich wrote: > Having a bad patch day apparently. Attached is a version that compiles. thanks, should be fixed in svn now -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070506/d6daeeda/attachment.pgp From vapier at gentoo.org Sun May 6 04:13:25 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 May 2007 07:13:25 -0400 Subject: uClibc 0.9.29 is out Message-ID: <200705060713.25537.vapier@gentoo.org> tagged, branched, and posted ... 0.9.29 is up -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070506/be1086a1/attachment.pgp From vapier at gentoo.org Sun May 6 04:20:36 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 May 2007 07:20:36 -0400 Subject: posix threading plans Message-ID: <200705060720.38053.vapier@gentoo.org> first, the status of linuxthreads ... when i first introduced the latest version of linuxthreads, the upstream status was fully maintained and no plans for this to end ... nptl wasnt even being considered. the idea was that the version of linuxthreads we had in our tree was pretty outdated and lacked fixes and features, so getting up to latest version was a good idea. all of these factors have changed significantly, so i'd like to simply cut the charades and do: - punt linuxthreads - rename linuxthreads.old back to just linuxthreads any qualms ? anyone see any value in getting linuxthreads more properly working ? only thing i can think of here that would be critical is newer ports and ports with opposite stack direction (like hppa) ... personally, i'd like to see linuxthreads go into maintenance only so we can all focus on NPTL ... but i'm a purely "looking forward" guy ... the plan for NPTL is to get the extraneous ports and patchsets (like arm and sh) floating around merged into the uClibc-nptl branch. then we need to get some outstanding issues resolved (ive seen replies to sjhill's commits about problems but no replies from him). then we can merge to trunk and try for 0.9.30. i see sjhill heading up most of this ... what do you think steven ? care to brain dump NPTL status/your thoughts in general/etc... ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070506/53bae0f6/attachment.pgp From joseph at codesourcery.com Sun May 6 04:53:22 2007 From: joseph at codesourcery.com (Joseph S. Myers) Date: Sun, 6 May 2007 11:53:22 +0000 (UTC) Subject: posix threading plans In-Reply-To: <200705060720.38053.vapier@gentoo.org> References: <200705060720.38053.vapier@gentoo.org> Message-ID: On Sun, 6 May 2007, Mike Frysinger wrote: > the plan for NPTL is to get the extraneous ports and patchsets (like arm and > sh) floating around merged into the uClibc-nptl branch. then we need to get I'm still concerned about the incomplete and undocumented status of merges from trunk into this branch. If I diff libc/sysdeps/linux/arm/, say, between trunk and branch, I see several changes that are reversions of patches made on trunk months ago, despite the last "Merge from trunk" commit being on 2007-04-21. This is the issue I explained at : unless every single merge commit (a) merges every change in the relevant range of trunk revisions and (b) states in the log message what those revisions are, it becomes pretty much impossible afterwards to work out what isn't merged, and so which diffs are real changes on the branch (and should be merged to trunk) and which are reversions of changes not merged from trunk (and such reversions mustn't be merged to trunk). For this reason, I still think a separate branch based on current trunk, getting only individual logical patches that have be checked line-by-line applied to it, and with no partial merges from trunk made to it, is the way to go. The ARM NPTL work was based on trunk at that time (and subsequently merged from newer trunk) precisely because the incomplete and undocumented merges made it infeasible to work based on the NPTL branch without getting regressions relative to trunk. -- Joseph S. Myers joseph at codesourcery.com From sjhill at realitydiluted.com Sun May 6 06:53:31 2007 From: sjhill at realitydiluted.com (Steven J. Hill) Date: Sun, 6 May 2007 08:53:31 -0500 Subject: posix threading plans In-Reply-To: References: <200705060720.38053.vapier@gentoo.org> Message-ID: <20070506135331.GA21905@real.realitydiluted.com> > I'm still concerned about the incomplete and undocumented status of merges > from trunk into this branch. If I diff libc/sysdeps/linux/arm/, say, > between trunk and branch, I see several changes that are reversions of > patches made on trunk months ago, despite the last "Merge from trunk" > commit being on 2007-04-21. This is the issue I explained at > : unless every > single merge commit (a) merges every change in the relevant range of trunk > revisions and (b) states in the log message what those revisions are, it > becomes pretty much impossible afterwards to work out what isn't merged, > and so which diffs are real changes on the branch (and should be merged to > trunk) and which are reversions of changes not merged from trunk (and such > reversions mustn't be merged to trunk). > Agreed, I am a little behind right now doing customer releases. I will gladly type up a status of things if people are interested. > For this reason, I still think a separate branch based on current trunk, > getting only individual logical patches that have be checked line-by-line > applied to it, and with no partial merges from trunk made to it, is the > way to go. > See below. > The ARM NPTL work was based on trunk at that time (and subsequently merged > from newer trunk) precisely because the incomplete and undocumented merges > made it infeasible to work based on the NPTL branch without getting > regressions relative to trunk. > No, when I began the NPTL work there was no one from Code Sourcery that even hinted another architecture was being worked on. There was no initial collaboration and you guys went your own way. The SuperH people actually did their work against the NPTL branch and kept me abreast of the work and made patches and development against the branch. -Steve From joseph at codesourcery.com Sun May 6 08:06:42 2007 From: joseph at codesourcery.com (Joseph S. Myers) Date: Sun, 6 May 2007 15:06:42 +0000 (UTC) Subject: posix threading plans In-Reply-To: <20070506135331.GA21905@real.realitydiluted.com> References: <200705060720.38053.vapier@gentoo.org> <20070506135331.GA21905@real.realitydiluted.com> Message-ID: On Sun, 6 May 2007, Steven J. Hill wrote: > > The ARM NPTL work was based on trunk at that time (and subsequently merged > > from newer trunk) precisely because the incomplete and undocumented merges > > made it infeasible to work based on the NPTL branch without getting > > regressions relative to trunk. > > > No, when I began the NPTL work there was no one from Code Sourcery that > even hinted another architecture was being worked on. There was no We made an announcement when we started the work . We studied the state of the branch available at the time, going through the tens of thousands of lines of diffs between trunk and branch line by line. We established that: * Merges had been incomplete and undocumented so there was no trunk revision we could compare against and get the NPTL changes and only the NPTL changes. * The branch was in an extremely incomplete state and large parts of the port had to be reimplemented because they were not publically available on the branch within the required timescale. We duly reimplemented these, so that when we first posted the port is was complete and usable. I believe we also asked you for any documentation you might have of the exact revisions and parts of revisions that had been merged or had yet to be merged to the branch, so the limitations of the merges could be repaired, but such documentation was not available, so the line-by-line comparison was necessary in order to update to then-current trunk. > initial collaboration and you guys went your own way. The SuperH people Our work was based on all the sources available at the time from the branch, but it required ARM changes that had been made on the trunk since the branch had been made, and only parts of those had been inconsistently merged to the branch. Because of the state of the merges to the branch and the requirement to be based on more recent sources than those on which the branch had been based, we went through the tens of thousands of lines of diffs by hand, identified those that represented genuine logical changes and updated them to be based on current trunk, thereby creating a three-way merge of: * Current trunk (complete current trunk, not an undocumented mixture of different trunk versions): * NPTL branch (that is, the changes available to the public on the branch at the time the development was required to be done). * The ARM NPTL changes. In fact the port was prepared twice: initially we based it on the branch, reimplementing all parts that had not been committed to the branch at that time and merging sufficient of the unmerged trunk changes to get something approximately working. But the requirement was for a port that did not regress relative to a more recent version of trunk than that on which the branch was based, so we went through all the diffs to identify those representing genuine NPTL changes, and merged those to a sufficiently recent version of trunk. The port has been updated several times since then. Each update posted has been based on an identified revision of trunk; there are no changes from that revision of trunk unmerged, and no changes from later revisions merged, so the diffs represent solely what is required to implement that port against that revision of trunk, without any extraneous reversions of unmerged trunk changes. > actually did their work against the NPTL branch and kept me abreast of > the work and made patches and development against the branch. Our work was based on the state of the branch at the time, but we were required to merge it with current trunk and the state of the branch meant the only way of doing this was going through all the diffs and removing those that were reversions of unmerged patches. Since then, we have maintained the patch on a basis of current trunk. If the NPTL branch had been exactly merged from a documented revision of trunk, so that every change from that revision of trunk were properly on the branch and the only diffs between that revision of trunk and the branch were the NPTL ones, and all trunk merges had followed that principle, it would have been more feasible to base work on the branch. But the branch was not in that state and is not in that state, and limitations of SVN make it impracticable to put a branch in that state if it gets out of it without as much effort as creating a new branch and applying patches by hand. What we need now is a multi-way merge of: * Current trunk; * NPTL branch, as it is now; * All the various ports. (Our merge is one of current trunk, as of an identified revision; NPTL branch, as it was when we started the work, and the ARM port.) I believe that to create the required merge, while guaranteeing not to accidentally revert any trunk change in the process, requires a new branch, where patches are applied one by one after line-by-line audits to make sure they do not contain any accidental reversions of past trunk changes. Each commit should be a logical unit, properly explained and posted to the list; it may be combined from many separate changes to the original branches. There is no automated way of extracting such clean diffs from SVN, because diffing the NPTL branch against *any* revision of trunk will produce a mixture of NPTL branch changes, reversions of trunk changes and (depending on the date) changes already on trunk since that particular revision. Such diffs can only be a starting point for line-by-line editing and checking - although new files added on the branch, for example, could probably be added at one go without such detailed checks. It is also necessary to carry out a technical comparison of the different approaches to the parts of the NPTL port that had not been publically implemented when we began the ARM work: we did one implementation to complete the ARM port within the timescale required, and you did another one to complete the MIPS port (or committed one that had been done previously but not made available before), and for each area where there are different approaches they both need to be considered on their merits. Some of these have been previously mentioned on the lists. For example, . -- Joseph S. Myers joseph at codesourcery.com From drow at false.org Sun May 6 08:42:35 2007 From: drow at false.org (Daniel Jacobowitz) Date: Sun, 6 May 2007 11:42:35 -0400 Subject: posix threading plans In-Reply-To: <20070506135331.GA21905@real.realitydiluted.com> References: <200705060720.38053.vapier@gentoo.org> <20070506135331.GA21905@real.realitydiluted.com> Message-ID: <20070506154235.GA2118@caradoc.them.org> On Sun, May 06, 2007 at 08:53:31AM -0500, Steven J. Hill wrote: > > The ARM NPTL work was based on trunk at that time (and subsequently merged > > from newer trunk) precisely because the incomplete and undocumented merges > > made it infeasible to work based on the NPTL branch without getting > > regressions relative to trunk. > > > No, when I began the NPTL work there was no one from Code Sourcery that > even hinted another architecture was being worked on. May I point out that these two statements don't disagree? When you began the NPTL work we weren't working on an ARM NPTL port. It wasn't until a whole lot later. I assure you, if we'd been working on one ourselves back when you were asking me NPTL questions, I'd have let you know. We'd have been much happier working together. I don't think revisiting the unfortunate circumstances is going to get us anywhere. Is there some way we can move on, and end up with a unified port? I don't care how we end up with an up-to-date branch as long as we do; from my experience with long-running branch development I tend to think that Joseph is right and that rebasing on top of a clean trunk branch is the way to go. -- Daniel Jacobowitz CodeSourcery From ehuang at ix.netcom.com Sun May 6 11:25:12 2007 From: ehuang at ix.netcom.com (Edward Huang) Date: Sun, 6 May 2007 11:25:12 -0700 Subject: What is XMALLOC and how it compares with malloc? In-Reply-To: <463A3C7A.5090008@avtrex.com> Message-ID: Dear David, Mike, Kevin, etc Thank you all for quick responses. Mike and David were right, it is a wrapper in rdesktop.c, thanks for pointing it out. Some of the code used Malloc, some used Xmalloc. So I've made it consistently use xmalloc as it has error checking Stil getting segmentation fault, trace show it occurs upon calling malloc Could this mean something is corrupting the heap / malloc's housekeeping such that malloc panics? -----Original Message----- From: David Daney [mailto:ddaney at avtrex.com] Sent: Thursday, May 03, 2007 12:48 PM To: ehuang at ix.netcom.com Cc: Mike Frysinger; uclibc at uclibc.org Subject: Re: What is XMALLOC and how it compares with malloc? ehuang at ix.netcom.com wrote: > Dear Mike, > > thanks for quickly getting back to me. > > The application is RDESKTOP. It has mess of both malloc and xmalloc. > Runs fine on Fedora Core (presumely glibc) but get segfaults under Cirrus ARM > linux which uses libcClibc-0.9.28.so So, I'm trying to understand and > trace the memory management. Whats frustrating is not finding any > decent explanation thru google about XMALLOC. Not even wikipedia! > Wow, not even in wikipedia?! Have you tried looking at the source code of the function? According to your grep, you should be able to find it in rdesktop.c. David Daney > > GREP MALLOC > > cache.c: text->data = xmalloc(length); > nwin.c: uint8 *d2 = xmalloc(width * height); > nwin.c: uint8 *d2 = xmalloc(width * height * (depth / 8)); > nwin.c: bmp = (GR_IMAGE_HDR*)malloc(sizeof(GR_IMAGE_HDR)); > nwin.c: bmp->palette = (MWPALENTRY*)malloc(2 * sizeof(MWPALENTRY)); > nwin.c: bmp->imagebits = (MWUCHAR*)malloc(datasize); > nwin.c:STATUS("doing malloc - sizeof %d\n",sizeof(GR_PALETTE) ); > nwin.c: pal = (GR_PALETTE*)malloc(sizeof(GR_PALETTE)); > nwin.c: STATUS("malloc error!\n"); > nwin.c: pixels = (GR_PIXELVAL*)malloc(cx * cy * depth); > orders.c: d2 = xmalloc(width*height); > orders.c: bmpdata = xmalloc(width * height); > orders.c: map.colours = xmalloc(3 * map.ncolours); > orders.c: rev_data = xmalloc(datasize); > rdesktop.c:#include /* malloc realloc free */ > rdesktop.c: char *errormsg = (char *)malloc(500); > rdesktop.c:/* malloc; exit if out of memory */ rdesktop.c:void > *xmalloc2(int l, char *s, int size) > rdesktop.c: void *mem = malloc(size); > rdesktop.c: ERROR("xmalloc %d\n", size); > rdesktop.c:/* malloc; exit if out of memory */ rdesktop.c:void > *xmalloc(int size) > rdesktop.c: void *mem = malloc(size); > rdesktop.c: ERROR("xmalloc %d\n", size); > rdp.c: rawdata = xmalloc(width * height); > rdp.c: rawdata = xmalloc(width * height); > secure.c: mcs_data.p = mcs_data.data = xmalloc(mcs_data.size); > tcp.c: in.data = xmalloc(in.size); > tcp.c: out.data = xmalloc(out.size); > From sjhill at realitydiluted.com Sun May 6 10:51:15 2007 From: sjhill at realitydiluted.com (Steven J. Hill) Date: Sun, 06 May 2007 12:51:15 -0500 Subject: posix threading plans In-Reply-To: <20070506154235.GA2118@caradoc.them.org> References: <200705060720.38053.vapier@gentoo.org> <20070506135331.GA21905@real.realitydiluted.com> <20070506154235.GA2118@caradoc.them.org> Message-ID: <463E1593.1000003@realitydiluted.com> Daniel Jacobowitz wrote: > > I don't think revisiting the unfortunate circumstances is going to get > us anywhere. Is there some way we can move on, and end up with a > unified port? I don't care how we end up with an up-to-date branch as > long as we do; from my experience with long-running branch development > I tend to think that Joseph is right and that rebasing on top of a > clean trunk branch is the way to go. > Do whatever you guys want and I will deal with it. -Steve From christian.michon at gmail.com Sun May 6 13:43:22 2007 From: christian.michon at gmail.com (Christian MICHON) Date: Sun, 6 May 2007 22:43:22 +0200 Subject: uClibc 0.9.29 is out In-Reply-To: <200705060713.25537.vapier@gentoo.org> References: <200705060713.25537.vapier@gentoo.org> Message-ID: <46d6db660705061343j16c5b697o403f5b3e3150d13@mail.gmail.com> woot, and congrats On 5/6/07, Mike Frysinger wrote: > tagged, branched, and posted ... 0.9.29 is up > -mike > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > -- Christian From rafael at riseup.net Sun May 6 06:46:13 2007 From: rafael at riseup.net (rafael2k) Date: Sun, 6 May 2007 10:46:13 -0300 Subject: posix threading plans In-Reply-To: <200705060720.38053.vapier@gentoo.org> References: <200705060720.38053.vapier@gentoo.org> Message-ID: <200705061046.15504.rafael@riseup.net> Em Domingo 06 Maio 2007 08:20, Mike Frysinger escreveu: > first, the status of linuxthreads ... when i first introduced the latest > version of linuxthreads, the upstream status was fully maintained and no > plans for this to end ... nptl wasnt even being considered. the idea was > that the version of linuxthreads we had in our tree was pretty outdated and > lacked fixes and features, so getting up to latest version was a good idea. > all of these factors have changed significantly, so i'd like to simply cut > the charades and do: > - punt linuxthreads > - rename linuxthreads.old back to just linuxthreads > any qualms ? anyone see any value in getting linuxthreads more properly > working ? only thing i can think of here that would be critical is newer > ports and ports with opposite stack direction (like hppa) ... personally, > i'd like to see linuxthreads go into maintenance only so we can all focus > on NPTL ... but i'm a purely "looking forward" guy ... thats nice! but one thing I'd really like to ask for is to not remove linuxthreads at all (nor in any near future), just like glibc did in 2.5 - so, w/ no linuxthreads support, no kernel 2.4 support, wich is very important for old pcs (486s)... thanx for all work!!! rafael diniz -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Eng. da Computa??o @ Unicamp R?dio Muda, radiolivre.org, TV Piolho, tvlivre.org, www.midiaindependente.org Chave PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2FF86098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20070506/e5bd3df8/attachment.pgp From vapier at gentoo.org Sun May 6 14:47:06 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 May 2007 17:47:06 -0400 Subject: posix threading plans In-Reply-To: <200705061046.15504.rafael@riseup.net> References: <200705060720.38053.vapier@gentoo.org> <200705061046.15504.rafael@riseup.net> Message-ID: <200705061747.06965.vapier@gentoo.org> On Sunday 06 May 2007, rafael2k wrote: > but one thing I'd really like to ask for is to not remove linuxthreads at > all (nor in any near future), just like glibc did in 2.5 - so, w/ no > linuxthreads support, no kernel 2.4 support, wich is very important for old > pcs (486s)... there are no plans to do this ... uClibc has a much more liberal view of things than glibc ... besides, linuxthreads couldnt even be considered for removal until existing ports are on nptl ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070506/1d9e6042/attachment.pgp From vapier at gentoo.org Sun May 6 15:04:20 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 May 2007 18:04:20 -0400 Subject: posix threading plans In-Reply-To: <463E1593.1000003@realitydiluted.com> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> Message-ID: <200705061804.23831.vapier@gentoo.org> On Sunday 06 May 2007, Steven J. Hill wrote: > Daniel Jacobowitz wrote: > > I don't think revisiting the unfortunate circumstances is going to get > > us anywhere. Is there some way we can move on, and end up with a > > unified port? I don't care how we end up with an up-to-date branch as > > long as we do; from my experience with long-running branch development > > I tend to think that Joseph is right and that rebasing on top of a > > clean trunk branch is the way to go. > > Do whatever you guys want and I will deal with it. this isnt exactly a helpful stance to take ... so what i'm hearing is: - mips/nptl only exists in branches/uClibc-nptl/ - the uClibc-nptl branch is in an unrecoverable state compared to trunk - arm/nptl exists against trunk - sjhill's work and codesourcery's work have some design decisions that need to be reconciled Carmelo: what's the status of the SuperH stuff ? so it would seem the best way forward is to rebranch trunk and move mips/arm/sh to that ... then once that has settled, we can move that branch back to trunk ... i have some things i'd like done for trunk, but nothing critical so it can wait (build system changes) seems like it'd be sane to bring at least Joseph and Carmelo on board ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070506/a5afb4ed/attachment.pgp From joseph at codesourcery.com Sun May 6 16:36:03 2007 From: joseph at codesourcery.com (Joseph S. Myers) Date: Sun, 6 May 2007 23:36:03 +0000 (UTC) Subject: posix threading plans In-Reply-To: <200705061804.23831.vapier@gentoo.org> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> Message-ID: On Sun, 6 May 2007, Mike Frysinger wrote: > seems like it'd be sane to bring at least Joseph and Carmelo on board ? Note that Jim Blandy and Paul Brook did much more of the ARM work than I did, so they would probably be better placed for this merging. I don't think any of us have SVN write access to the uClibc repository at present. -- Joseph S. Myers joseph at codesourcery.com From sjhill at realitydiluted.com Sun May 6 16:49:40 2007 From: sjhill at realitydiluted.com (Steven J. Hill) Date: Sun, 06 May 2007 18:49:40 -0500 Subject: posix threading plans In-Reply-To: <200705061804.23831.vapier@gentoo.org> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> Message-ID: <463E6994.30708@realitydiluted.com> Mike Frysinger wrote: >> clean trunk branch is the way to go. >> Do whatever you guys want and I will deal with it. > > this isnt exactly a helpful stance to take ... > Sorry for the shortness of the response, but with my 2 year old son screaming next to me to play chase, I could not get much more typed. My stance is to do what is best for the community at large. I am more than happy resolve the different branches. Carmelo's SuperH stuff is against the uClibc-NPTL branch last I knew. My NPTL thread code is from glibc 20050823, clearly older code. Joseph, what glibc version did you reference for the ARM port? > so what i'm hearing is: > - mips/nptl only exists in branches/uClibc-nptl/ > - the uClibc-nptl branch is in an unrecoverable state compared to trunk > - arm/nptl exists against trunk > - sjhill's work and codesourcery's work have some design decisions that need > to be reconciled > I would like to have Carmelo's latest patch against uClibc-NPTL branch. If the changes are not severe, then I would like to get SuperH into the current NPTL branch first. If there are too many changes, then let's go ahead and create a new branch and start merging. Mike, I can create the branch so you can focus on trunk. Carmelo and Joseph, after I hear back on the glibc reference version for ARM and what state the SuperH port is in, we can proceed. -Steve From carmelo.amoroso at st.com Mon May 7 05:12:54 2007 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Mon, 07 May 2007 14:12:54 +0200 Subject: [PATCH] sh4: use optimized asm version of memcpy - add config option to support backward copying In-Reply-To: <20070326020203.GA13058@linux-sh.org> References: <4601090C.3050307@st.com> <200703250918.34372.vapier@gentoo.org> <20070326020203.GA13058@linux-sh.org> Message-ID: <463F17C6.2040704@st.com> Paul Mundt wrote: > On Sun, Mar 25, 2007 at 09:18:33AM -0400, Mike Frysinger wrote: > >> On Wednesday 21 March 2007, Carmelo AMOROSO wrote: >> >>> I'm currently using on uClibc-nptl for sh4 an optimized version >>> of the memcpy function (from Stuart Menefy @STMicroelectronics). >>> This implementation is based on 'backward copying' >>> and brakes the current implementation of 'memmove' >>> (libc/string/generic/memmove.c) >>> that, as clearly stated, assumes memcpy does a forward copying. >>> >>> The attached patch provides a solution for this adding a config option >>> to specify what kind of memcpy implementation the architecture provides. >>> In this way the memmove works with both implementation. >>> >> if anything, this option should not be exported for the user to try and figure >> out ... either the architecture provides it or it doesnt which means it'd be >> a hardcoded selection in the arch-specific config.in files ... >> >> wouldnt it be simpler to provide a superh optimized memmove/memcpy ? then it >> wouldnt matter what the generic implementations assume ... >> > > It has to be split out separately for sh4, given the movca.l usage. > Hi All, I've updated the previous patch to keep into account both suggestions made by Mike and Paul. A brief explanation of the changes follows: extra/Configs/Config.in -> set the TARGET_SUBARCH for the sh4 architecture extra/Configs/Config.in.sh -> set on the ARCH_HAS_BWD_MEMCPY for sh4 architecture only libc/string/sh/sh4 -> new file memcpy.S (sh4 specific) libc/string/generic/memmove.c -> use the new macro __ARCH_HAS_BWD_MEMCPY__ instead of #if 1 libc/string/generic/memcpy.c -> move static function from C source to common header file with some reorder libc/string/generic/memcopy.h -> "" libc/string/Makefile.in -> add code the manage subarch specific code in addition to the arch specific one. Any comments are welcome. Cheers, Carmelo -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: backward_memcpy_sh4.patch Url: http://busybox.net/lists/uclibc/attachments/20070507/9f42599a/attachment-0001.diff From rob at landley.net Mon May 7 09:30:21 2007 From: rob at landley.net (Rob Landley) Date: Mon, 7 May 2007 12:30:21 -0400 Subject: posix threading plans In-Reply-To: <200705060720.38053.vapier@gentoo.org> References: <200705060720.38053.vapier@gentoo.org> Message-ID: <200705071230.22281.rob@landley.net> On Sunday 06 May 2007 7:20 am, Mike Frysinger wrote: > so i'd like to simply cut > the charades and do: > - punt linuxthreads > - rename linuxthreads.old back to just linuxthreads Works for me. Ancient threading for the 2.2/2.4 guys might as well be ancient, and modern threading is nptl. No point in putting fresh effort into obsolete threading. Rob From rob at landley.net Mon May 7 09:34:45 2007 From: rob at landley.net (Rob Landley) Date: Mon, 7 May 2007 12:34:45 -0400 Subject: What is XMALLOC and how it compares with malloc? In-Reply-To: References: Message-ID: <200705071234.46343.rob@landley.net> On Sunday 06 May 2007 2:25 pm, Edward Huang wrote: > Dear David, Mike, Kevin, etc > > Thank you all for quick responses. Mike and David were right, it is a > wrapper in rdesktop.c, thanks for pointing it out. Some of the code used > Malloc, some used Xmalloc. So I've made it consistently use xmalloc as it > has error checking > > Stil getting segmentation fault, trace show it occurs upon calling malloc > > Could this mean something is corrupting the heap / malloc's housekeeping > such that malloc panics? That's most likely what's happening, yes. Could be a double free somewhere, could be something writing outside of its' allocation. Various tools exist to help track this sort of thing down. Valgrind and electric fence come to mind. Haven't personally used either. Rob From jimb at codesourcery.com Mon May 7 10:41:22 2007 From: jimb at codesourcery.com (Jim Blandy) Date: Mon, 07 May 2007 10:41:22 -0700 Subject: posix threading plans In-Reply-To: (Joseph S. Myers's message of "Sun, 6 May 2007 23:36:03 +0000 (UTC)") References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> Message-ID: Steve Hill wrote: > My NPTL thread code is from glibc 20050823, clearly older code. Joseph, > what glibc version did you reference for the ARM port? Our ARM port took the libpthreads/nptl directory from uClibc-nptl, so it's based on the same original sources. We used SVK to stay up to date with the uClibc NPTL branch, and later the uClibc trunk, but it wasn't a goal to track the upstream NPTL sources. > I would like to have Carmelo's latest patch against uClibc-NPTL branch. If the > changes are not severe, then I would like to get SuperH into the current NPTL > branch first. If there are too many changes, then let's go ahead and create a > new branch and start merging. It seems to me that we need to plan up front how we're going to merge to the trunk. I haven't followed development since last fall, but the last I knew, the uClibc-nptl branch wasn't up to date with respect to any individual trunk version, which means merging it to the trunk requires going through the patch versus the closest trunk rev we can find line by line. That seems like a heck of a lot of work. The ARM port is up to date with respect to a documented uClibc trunk revision. A diff between that trunk rev and the ARM port gets you exactly and only the NPTL changes. Merging that entails bringing in trunk changes since that point, resolving conflicts, and addressing regressions. Steve, have you tried simply dumping the MIPS-specific stuff from libpthread/nptl into the ARM port branch and seeing how it works? It might not be that bad. It'd be worth a try, to save that line-by-line work. (I sure didn't enjoy it. :) ) From kraj at mvista.com Mon May 7 10:48:28 2007 From: kraj at mvista.com (Khem Raj) Date: Mon, 07 May 2007 10:48:28 -0700 Subject: posix threading plans In-Reply-To: <463E6994.30708@realitydiluted.com> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> <463E6994.30708@realitydiluted.com> Message-ID: <463F666C.2010905@mvista.com> Steven J. Hill wrote: > Mike Frysinger wrote: > >>> clean trunk branch is the way to go. >>> Do whatever you guys want and I will deal with it. >>> >> this isnt exactly a helpful stance to take ... >> >> > Sorry for the shortness of the response, but with my 2 year old son > screaming next to me to play chase, I could not get much more typed. > My stance is to do what is best for the community at large. I am more > than happy resolve the different branches. Carmelo's SuperH stuff is > against the uClibc-NPTL branch last I knew. > > My NPTL thread code is from glibc 20050823, clearly older code. Joseph, > what glibc version did you reference for the ARM port? > > >> so what i'm hearing is: >> - mips/nptl only exists in branches/uClibc-nptl/ >> - the uClibc-nptl branch is in an unrecoverable state compared to trunk >> - arm/nptl exists against trunk >> - sjhill's work and codesourcery's work have some design decisions that need >> to be reconciled >> >> > I would like to have Carmelo's latest patch against uClibc-NPTL branch. If the > changes are not severe, then I would like to get SuperH into the current NPTL > branch first. If there are too many changes, then let's go ahead and create a > new branch and start merging. > > Mike, I can create the branch so you can focus on trunk. Carmelo and Joseph, > after I hear back on the glibc reference version for ARM and what state the > SuperH port is in, we can proceed. > > -Steve > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > We have all work for ARM MIPS and SH done in one place or other. ARM port started off from MIPS nptl branch but I think its been updated with lots of nptl stuff from glibc as it was done recently so I believe the ARM port might be a bit more recent. So I think creating a new branch and merging all different ports into one is the best way to go in my opnion and also addressing design issues that come along. As of now I have tried to keep the arm nptl port functional on trunk. Thanks -Khem From robert.dodier at gmail.com Mon May 7 11:47:24 2007 From: robert.dodier at gmail.com (Robert Dodier) Date: Mon, 7 May 2007 12:47:24 -0600 Subject: __malloc_lock undefined symbol in ptfork.c Message-ID: Hello, I am trying to build uClibc for ARM. For the record, I am working with Buildroot on Gumstix (small computers with Marvell PXA processors). I am trying to build uClibc-0.9.28.3. The attempt to build libpthread fails because ptfork.c references __malloc_lock and that does not appear to be defined anywhere in the uClibc code. Does anyone know how I can resolve this? I notice that there are #warning hack alert messages just before the references to __malloc_lock. This suggests to me that there is something not-quite-finished about these __malloc_lock references. Looking at the svn log doesn't seem to help; the __malloc_lock stuff seems to have been introduced in http://www.uclibc.org/cgi-bin/viewcvs.cgi?rev=17534&view=rev The comment is only "even more accumulated fixes from trunk"; looking at ptfork.c on the trunk, I don't see the __malloc_lock stuff. Can I just revert r17534 in ptfork.c ? Thanks for any light you can shed on these questions. Robert Dodier From vapier at gentoo.org Mon May 7 14:36:16 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 7 May 2007 17:36:16 -0400 Subject: __malloc_lock undefined symbol in ptfork.c In-Reply-To: References: Message-ID: <200705071736.16799.vapier@gentoo.org> On Monday 07 May 2007, Robert Dodier wrote: > I am trying to build uClibc-0.9.28.3. The attempt to build > libpthread fails because ptfork.c references __malloc_lock > and that does not appear to be defined anywhere in the > uClibc code. Does anyone know how I can resolve this? compress your .config and post it to the list -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070507/8aa157cf/attachment.pgp From rob at landley.net Mon May 7 14:37:47 2007 From: rob at landley.net (Rob Landley) Date: Mon, 7 May 2007 17:37:47 -0400 Subject: posix threading plans In-Reply-To: References: <200705060720.38053.vapier@gentoo.org> <20070506135331.GA21905@real.realitydiluted.com> Message-ID: <200705071737.47389.rob@landley.net> On Sunday 06 May 2007 11:06 am, Joseph S. Myers wrote: > But the branch was not in that state and is not in that state, and > limitations of SVN make it impracticable to put a branch in that state if > it gets out of it without as much effort as creating a new branch and > applying patches by hand. I note that I've been maintaining a Mercurial mirror of the uClibc repository for some time now, due to the numerous limitation of SVN. ("Better than CVS" is damning with faint praise.) http://landley.net/hg/uclibc (This may not be useful, but I thought I'd mention it. Someday I need to upgrade tailor to pull tags...) > What we need now is a multi-way merge of: > > * Current trunk; > > * NPTL branch, as it is now; > > * All the various ports. Modern distributed source control systems (mercurial, git, bitkeeper, etc) can do multi-way merges. SVN is not a modern source control system, and I got tired of fighting it a while back. That said, I'm under the impression that now that 0.9.29 is now, NPTL stuff can start being applied to trunk, to drain the various branches into mainline with mainline being the marshalling point. (Is this not the case?) Rob From robert.dodier at gmail.com Mon May 7 14:49:56 2007 From: robert.dodier at gmail.com (Robert Dodier) Date: Mon, 7 May 2007 15:49:56 -0600 Subject: __malloc_lock undefined symbol in ptfork.c In-Reply-To: <200705071736.16799.vapier@gentoo.org> References: <200705071736.16799.vapier@gentoo.org> Message-ID: On 5/7/07, Mike Frysinger wrote: > On Monday 07 May 2007, Robert Dodier wrote: > > I am trying to build uClibc-0.9.28.3. The attempt to build > > libpthread fails because ptfork.c references __malloc_lock > > and that does not appear to be defined anywhere in the > > uClibc code. Does anyone know how I can resolve this? > > compress your .config and post it to the list OK, I've attached the gzip-compressed .config to this message. I created a patch to revert the __malloc_lock stuff and then libpthread and the rest of uClibc builds successfully. Although of course I wonder if/when I'll bump into something that tickles whatever __malloc_lock was supposed to resolve. Thanks for your help, Robert Dodier -------------- next part -------------- A non-text attachment was scrubbed... Name: dodier-uClibc-config.gz Type: application/x-gzip Size: 1542 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20070507/634f0e9d/attachment.bin From carmelo.amoroso at st.com Tue May 8 08:20:52 2007 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 08 May 2007 17:20:52 +0200 Subject: posix threading plans In-Reply-To: <200705061804.23831.vapier@gentoo.org> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> Message-ID: <46409554.9020206@st.com> Mike Frysinger wrote: > On Sunday 06 May 2007, Steven J. Hill wrote: > >> Daniel Jacobowitz wrote: >> >>> I don't think revisiting the unfortunate circumstances is going to get >>> us anywhere. Is there some way we can move on, and end up with a >>> unified port? I don't care how we end up with an up-to-date branch as >>> long as we do; from my experience with long-running branch development >>> I tend to think that Joseph is right and that rebasing on top of a >>> clean trunk branch is the way to go. >>> >> Do whatever you guys want and I will deal with it. >> > > this isnt exactly a helpful stance to take ... > > so what i'm hearing is: > - mips/nptl only exists in branches/uClibc-nptl/ > - the uClibc-nptl branch is in an unrecoverable state compared to trunk > - arm/nptl exists against trunk > - sjhill's work and codesourcery's work have some design decisions that need > to be reconciled > > Carmelo: what's the status of the SuperH stuff ? > Hi Mike, here it's the SuperH (specifically sh4 core) status: - code base is uClibc-nptl branch: svn revision 17694 (Feb 2007) **** BUT **** - all patch I've already posted to the ML and committed to trunk (by you, Jocke, and others) are included into nptl port (some of them are sh4 specific, some other general) - the build system is essentially trunk based (i.e. we use libc-y/libc-shared-y/libc-static-y while nptl branch currently is using the old implementation based on libc-so-y) - the common TLS part of the dynamic linker differs from the current nptl branch version as I've already highlighted in a old post (see message: http://www.uclibc.org/lists/uclibc/2006-August/016263.html), and seems the Codesourcery patch address this similarly. - the design I applied to handle cancellation point differs from the mips solution, and is essentially based on Codesourcery patch (see the message above) - Some fixes committed to trunk have already merged with our nptl port so, even if we have a few patches suitable to produce, starting from the official nptl branch (as checked out from SVN), a complete nptl port for sh4, I'd prefer starting from a freshen branch based on latest trunk. This should avoid in my opinion any extra effort and bring into the nptl work all the latest work done on trunk. > so it would seem the best way forward is to rebranch trunk and move > mips/arm/sh to that ... then once that has settled, we can move that branch > back to trunk ... i have some things i'd like done for trunk, but nothing > critical so it can wait (build system changes) > > seems like it'd be sane to bring at least Joseph and Carmelo on board ? > Thanks Mike, I'll try to do the best I can... should I need a svn account with write rights? Regards, Carmelo > -mike > From carmelo.amoroso at st.com Tue May 8 08:27:40 2007 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 08 May 2007 17:27:40 +0200 Subject: posix threading plans In-Reply-To: <463E6994.30708@realitydiluted.com> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> <463E6994.30708@realitydiluted.com> Message-ID: <464096EC.3000806@st.com> Steven J. Hill wrote: > I would like to have Carmelo's latest patch against uClibc-NPTL branch. If the > changes are not severe, then I would like to get SuperH into the current NPTL > branch first. If there are too many changes, then let's go ahead and create a > new branch and start merging. > Hi Steve, no problem to distribute the SuperH patches... I've asked my Sys Admin if we can put them somewhere on our STLinux website, or simply emailing them to you (and uClibc ML).. I'll notify when done. It's up to you to deciding if the changes are too sever or not, and eventually you are free to commit them on the nptl branch.... but my opinion is to start from a new branch from now and avoid double merges (for a lot of reasons as in my reply to Mike). - Carmelo From sjhill at realitydiluted.com Tue May 8 08:37:21 2007 From: sjhill at realitydiluted.com (Steven J. Hill) Date: Tue, 8 May 2007 10:37:21 -0500 Subject: posix threading plans In-Reply-To: <464096EC.3000806@st.com> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> <463E6994.30708@realitydiluted.com> <464096EC.3000806@st.com> Message-ID: <20070508153721.GA28507@real.realitydiluted.com> On Tue, May 08, 2007 at 05:27:40PM +0200, Carmelo AMOROSO wrote: > > Hi Steve, no problem to distribute the SuperH patches... I've asked my > Sys Admin if we can put them > somewhere on our STLinux website, or simply emailing them to you (and > uClibc ML).. I'll notify when done. > It's up to you to deciding if the changes are too sever or not, and > eventually you are free to commit them > on the nptl branch.... but my opinion is to start from a new branch from > now and avoid double merges > (for a lot of reasons as in my reply to Mike). > Agreed. Don't worry about sending me patches. I'll go ahead and create a branch called 'uClibc-NPTL-merge' and we can get going on this. Mike, can you create write access for Carmelo. For the ARM side, which person from CodeSourcery is going to do commits? -Steve From joakim.tjernlund at transmode.se Tue May 8 09:14:46 2007 From: joakim.tjernlund at transmode.se (Joakim Tjernlund) Date: Tue, 8 May 2007 18:14:46 +0200 Subject: posix threading plans In-Reply-To: <46409554.9020206@st.com> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> <46409554.9020206@st.com> Message-ID: <1178640886.5460.71.camel@gentoo-jocke.transmode.se> On Tue, 2007-05-08 at 17:20 +0200, Carmelo AMOROSO wrote: > Mike Frysinger wrote: > > On Sunday 06 May 2007, Steven J. Hill wrote: > > > >> Daniel Jacobowitz wrote: > >> > >>> I don't think revisiting the unfortunate circumstances is going to get > >>> us anywhere. Is there some way we can move on, and end up with a > >>> unified port? I don't care how we end up with an up-to-date branch as > >>> long as we do; from my experience with long-running branch development > >>> I tend to think that Joseph is right and that rebasing on top of a > >>> clean trunk branch is the way to go. > >>> > >> Do whatever you guys want and I will deal with it. > >> > > > > this isnt exactly a helpful stance to take ... > > > > so what i'm hearing is: > > - mips/nptl only exists in branches/uClibc-nptl/ > > - the uClibc-nptl branch is in an unrecoverable state compared to trunk > > - arm/nptl exists against trunk > > - sjhill's work and codesourcery's work have some design decisions that need > > to be reconciled > > > > Carmelo: what's the status of the SuperH stuff ? > > > Hi Mike, > here it's the SuperH (specifically sh4 core) status: > - code base is uClibc-nptl branch: svn revision 17694 (Feb 2007) > **** BUT **** > - all patch I've already posted to the ML and committed to trunk (by > you, Jocke, and others) are included > into nptl port (some of them are sh4 specific, some other general) For what it is worth, I prefer Carmelos changes to the _dl_find_hash() function. I would like to see the common changes for NTPL integrated first. Also, since this is THE feature for the next release, why not work in trunk? Jocke From kraj at mvista.com Tue May 8 09:38:31 2007 From: kraj at mvista.com (Khem Raj) Date: Tue, 08 May 2007 09:38:31 -0700 Subject: posix threading plans In-Reply-To: <1178640886.5460.71.camel@gentoo-jocke.transmode.se> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> <46409554.9020206@st.com> <1178640886.5460.71.camel@gentoo-jocke.transmode.se> Message-ID: <4640A787.6090009@mvista.com> Joakim Tjernlund wrote: > at it is worth, I prefer Carmelos changes to the _dl_find_hash() > function. > I would like to see the common changes for NTPL integrated first. > Also, since this is THE feature for the next release, why not work in > trunk? > thats not a bad idea either. > Jocke > > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > From sjhill at realitydiluted.com Tue May 8 10:07:10 2007 From: sjhill at realitydiluted.com (Steven J. Hill) Date: Tue, 8 May 2007 12:07:10 -0500 Subject: posix threading plans In-Reply-To: <1178640886.5460.71.camel@gentoo-jocke.transmode.se> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> <46409554.9020206@st.com> <1178640886.5460.71.camel@gentoo-jocke.transmode.se> Message-ID: <20070508170710.GB28507@real.realitydiluted.com> > For what it is worth, I prefer Carmelos changes to the _dl_find_hash() > function. > Agreed. Mine is a hack right now and I had not gotten around to using Carmelos'. > I would like to see the common changes for NTPL integrated first. > Also, since this is THE feature for the next release, why not work in > trunk? > I'm assuming that nightly builds are still being done from trunk? If so, then I have no problem with this. Nightly builds using linuxthreads will need to be mandatory. -Steve From paul at codesourcery.com Tue May 8 10:12:24 2007 From: paul at codesourcery.com (Paul Brook) Date: Tue, 8 May 2007 18:12:24 +0100 Subject: posix threading plans In-Reply-To: <20070508153721.GA28507@real.realitydiluted.com> References: <200705060720.38053.vapier@gentoo.org> <464096EC.3000806@st.com> <20070508153721.GA28507@real.realitydiluted.com> Message-ID: <200705081812.26100.paul@codesourcery.com> > Agreed. Don't worry about sending me patches. I'll go ahead and create a > branch called 'uClibc-NPTL-merge' and we can get going on this. > > Mike, can you create write access for Carmelo. For the ARM side, which > person from CodeSourcery is going to do commits? I'm probably the best person from CodeSourcery to do this. I worked on the ARM NPTL port and, in the short term at least, have more time available then Jim Blandy. Paul From joakim.tjernlund at transmode.se Tue May 8 10:17:29 2007 From: joakim.tjernlund at transmode.se (Joakim Tjernlund) Date: Tue, 08 May 2007 19:17:29 +0200 Subject: posix threading plans In-Reply-To: <20070508170710.GB28507@real.realitydiluted.com> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> <46409554.9020206@st.com> <1178640886.5460.71.camel@gentoo-jocke.transmode.se> <20070508170710.GB28507@real.realitydiluted.com> Message-ID: <1178644649.5460.80.camel@gentoo-jocke.transmode.se> On Tue, 2007-05-08 at 12:07 -0500, Steven J. Hill wrote: > > For what it is worth, I prefer Carmelos changes to the _dl_find_hash() > > function. > > > Agreed. Mine is a hack right now and I had not gotten around to using > Carmelos'. Possibly one could use a static inline wrapper function for the non TLS case, that way you don't need to wrap the call sites with #ifdef USE_TLS > > > I would like to see the common changes for NTPL integrated first. > > Also, since this is THE feature for the next release, why not work in > > trunk? > > > I'm assuming that nightly builds are still being done from trunk? If so, > then I have no problem with this. Nightly builds using linuxthreads will > need to be mandatory. Dunno about the nightly builds, but working in trunk means that error for non NPTL/TLS will be detected quicker even without the nightly builds and you get some more eyes scanning the changes. Jocke From rep.dot.nop at gmail.com Tue May 8 14:08:47 2007 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 8 May 2007 23:08:47 +0200 Subject: posix threading plans In-Reply-To: <1178644649.5460.80.camel@gentoo-jocke.transmode.se> References: <200705060720.38053.vapier@gentoo.org> <20070506154235.GA2118@caradoc.them.org> <463E1593.1000003@realitydiluted.com> <200705061804.23831.vapier@gentoo.org> <46409554.9020206@st.com> <1178640886.5460.71.camel@gentoo-jocke.transmode.se> <20070508170710.GB28507@real.realitydiluted.com> <1178644649.5460.80.camel@gentoo-jocke.transmode.se> Message-ID: <20070508210847.GB15146@aon.at> On Tue, May 08, 2007 at 07:17:29PM +0200, Joakim Tjernlund wrote: >On Tue, 2007-05-08 at 12:07 -0500, Steven J. Hill wrote: >> > I would like to see the common changes for NTPL integrated first. >> > Also, since this is THE feature for the next release, why not work in >> > trunk? >> > >> I'm assuming that nightly builds are still being done from trunk? If so, >> then I have no problem with this. Nightly builds using linuxthreads will >> need to be mandatory. > >Dunno about the nightly builds, but working in trunk means that http://uclibc.org:8010/ >error for non NPTL/TLS will be detected quicker even without the >nightly builds and you get some more eyes scanning the changes. Given that we have a fresh release for people to use, this sounds fine. Up to vapier, though. From waxinwaxout at hotmail.com Wed May 9 05:47:35 2007 From: waxinwaxout at hotmail.com (Mr. Miyagi) Date: Wed, 09 May 2007 07:47:35 -0500 Subject: MIPS32 Dynamic Linker Characteristics ...no Message-ID: I can't get dynamic shared object loading for C++ sources. Apparently, the linker is not even capable of creating shared libraries for C++ while it's reported being capable of producing shared libraries for C. I'm using uclibc-0.9.28.2 through OpenWRT's toolchain. I compile the toolchain myself and use the resulting SDK to compile my own sources for the intended MIPS32 architecture. The toolchain is running on x86 architecture and cross compiles to MIPS32. The build of the toolchain produced libstdc++ (6.0.3) which is reported to be an ELF 32bit LSB shared object, MIPS, version 1 (SYSV). 'configure' (on my own sources) reports (below) shared libraries are possible when using ...gcc as the linker, but not when using ...g++ as the linker, although the same linker is apparently used in both instances. I don't know what's preventing the use of shared libraries for C++. I checked the uClibc sources involved in building the toolchain. One of the possible (far-fetched?) causes is that the tree of ldso includes mips but not mipsel causing some kind of problems as the toolchain is little endian, although I'd expect 'mips' to be followed in this case? And this can't be right as this would hinder C shared libraries as well. I'm also wondering to what extent the kernel (linux 2.4.34) options are related to this. The kernel build uses the following (possibly related) options: CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_ELF_AOUT is not set # CONFIG_MIPS32_COMPAT is not set # CONFIG_MIPS32_O32 is not set # CONFIG_MIPS32_N32 is not set # CONFIG_BINFMT_ELF32 is not set # CONFIG_BINFMT_MISC is not set I don't immediately know if the lack of MIPS32 options is causing this problem. But the CONFIG_BINFMT_ELF_AOUT annotation states that: 'The kernel may support ELF executables which use an a.out format interpreter (dynamic linker) and/or a.out shared libraries, in addition to the usual ELF-ELF setups. You shouldn't need this.'. I'm wondering if I do need this, i.e. is there an a.out format interpreter involved with uclibc's dynamic linker? But if this is the cause, I'd expect the C shared libraries to be hindered in this way as well. So (from configure output below) I (we) can produce position independant code, shared libraries for C, but not shared libraries for C++ code although the toolchain produces libstdc++ as a shared library (inferring in this case that libstdc++ is written in C?). A pointer (shove) in the right direction is most appreciated. Thanks, Miyagi From vapier at gentoo.org Thu May 10 16:49:44 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 10 May 2007 19:49:44 -0400 Subject: MIPS32 Dynamic Linker Characteristics ...no In-Reply-To: References: Message-ID: <200705101949.44631.vapier@gentoo.org> On Wednesday 09 May 2007, Mr. Miyagi wrote: > I can't get dynamic shared object loading for C++ sources. Apparently, the > linker is not even capable of creating shared libraries for C++ while it's > reported being capable of producing shared libraries for C. incorrect ... you've hit some issues with libtool not recognizing your tuple properly, nothing more ... uClibc is fully capable of doing C and C++ code (not that it should even really matter ... that's mostly gcc's realm) > The build of the toolchain produced libstdc++ (6.0.3) which is reported to > be an ELF 32bit LSB shared object, MIPS, version 1 (SYSV). > > 'configure' (on my own sources) reports (below) shared libraries are > possible when using ...gcc as the linker, but not when using ...g++ as the > linker, although the same linker is apparently used in both instances. this is probably partly libtool's fault and partly file's fault and partly other random autotool stuff your best bet is to update to the very latest package of "file", "libtool", "automake", and "autoconf" and then regenerate all the autotool files in the package you're trying to compile -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20070510/1cd29d35/attachment.pgp From waxinwaxout at hotmail.com Fri May 11 08:47:04 2007 From: waxinwaxout at hotmail.com (Mr. Miyagi) Date: Fri, 11 May 2007 10:47:04 -0500 Subject: MIPS32 Dynamic Linker Characteristics ...no In-Reply-To: <200705101949.44631.vapier@gentoo.org> Message-ID: >From: Mike Frysinger >To: uclibc at uclibc.org >CC: "Mr. Miyagi" >Subject: Re: MIPS32 Dynamic Linker Characteristics ...no >Date: Thu, 10 May 2007 19:49:44 -0400 > >On Wednesday 09 May 2007, Mr. Miyagi wrote: > > I can't get dynamic shared object loading for C++ sources. Apparently, >the > > linker is not even capable of creating shared libraries for C++ while >it's > > reported being capable of producing shared libraries for C. > >incorrect ... you've hit some issues with libtool not recognizing your >tuple >properly, nothing more ... uClibc is fully capable of doing C and C++ code >(not that it should even really matter ... that's mostly gcc's realm) Ok, thanks for pointing this out. This helped me find the problem/solution (below). > > > The build of the toolchain produced libstdc++ (6.0.3) which is reported >to > > be an ELF 32bit LSB shared object, MIPS, version 1 (SYSV). > > > > 'configure' (on my own sources) reports (below) shared libraries are > > possible when using ...gcc as the linker, but not when using ...g++ as >the > > linker, although the same linker is apparently used in both instances. > >this is probably partly libtool's fault and partly file's fault and partly >other random autotool stuff > >your best bet is to update to the very latest package >of "file", "libtool", "automake", and "autoconf" and then regenerate all >the >autotool files in the package you're trying to compile That's a money-making bet. I'm using libtool 1.5.22, autoconf 2.59. I have a src dir (top_srcdir) and then separte build dirs per target. I actually regenerate most of the autotools files in the top_srcdir from my own script which takes global parameters/directives to generate the autotool files. The problem is that after running configure, a libtool script is installed in $top_builddir (apparently) coming from the host (x86_32). This works fine when targetting the host architecture (produces shared libraries and dynamically loadable modules) but this script prevents shared libraries from being built when targetting MIPS. (After a whole lot of investigating) I found the libtool script from the (OpenWRT) SDK (in it's 'bin' directory), copied that to the top_builddir pertaining to a MIPS build (after running $top_srcdir/configure) and voila, shared libraries, dynamically shared modules and sliced bread. That was a great tip, thanks for this. Miyagi _________________________________________________________________ Now you can see trouble?before he arrives http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_protection_0507 From rgetz at blackfin.uclinux.org Sat May 12 20:06:26 2007 From: rgetz at blackfin.uclinux.org (Robin Getz) Date: Sat, 12 May 2007 23:06:26 -0400 Subject: threads and libc/stdlib/malloc Message-ID: <200705122306.27039.rgetz@blackfin.uclinux.org> Hi. In Oct of 2002 (based on a 2.4.19 kernel), Miles Bader added support for pthreads in the malloc code for uClinux (noMMU), and needed (at the time) to work around some issues in broken kernel munmap. Discussion is at: http://osdir.com/ml/lib.uclibc.general/2002-10/msg00100.html Commit is at: http://uclibc.org/cgi-bin/viewcvs.cgi?rev=5634&view=rev Commit message is: * Add support for uClinux's broken munmap, contingent on __UCLIBC_UCLINUX_BROKEN_MUNMAP__ (which is currently not defined anywhere). This makes other cases a tiny bit less efficient too. Question: Jie noticed when digging into an issue, that there is a race condition in malloc/free for multi-threading applications. When Miles added things, to work around the 2.4 kernel's munmap brokeness in noMMU mode, libc/stdlib/malloc in uClibc uses a linked list of structure mmb to deal with the problem in user space. The issue is the linked list is not thread safe... Can someone with the history describe the "broken" munmap, and we can determine if it still exists on recent kernels (which have much better mmap/munmap support due to David Howells' efforts). Jie has a patch for the existing uClibc's malloc (libc/stdlib/malloc) for the issues that he found, but I was wondering if the best thing would be to remove the UCLINUX_BROKEN_MUNMAP__ (because it isn't anymore), or if the userspace workarounds are still needed on a 2.6.x kernel? Thanks -Robin From will.newton at gmail.com Mon May 14 04:31:38 2007 From: will.newton at gmail.com (Will Newton) Date: Mon, 14 May 2007 12:31:38 +0100 Subject: posix threading plans In-Reply-To: <200705060720.38053.vapier@gentoo.org> References: <200705060720.38053.vapier@gentoo.org> Message-ID: <87a5b0800705140431u569d082cr273f0f2649033ef2@mail.gmail.com> On 5/6/07, Mike Frysinger wrote: Sorry for the late reply, > any qualms ? anyone see any value in getting linuxthreads more properly > working ? only thing i can think of here that would be critical is newer > ports and ports with opposite stack direction (like hppa) ... personally, i'd I'm working with such a port (backwards stack) and what we are using here is the "broken" new LinuxThreads. Do you know what is specifically broken with it? I don't recall making substantive changes to get it working, just minor tweaks. I haven't tested it on any platform other than our own however. From thekevinday at gmail.com Mon May 14 20:03:05 2007 From: thekevinday at gmail.com (Kevin Day) Date: Mon, 14 May 2007 21:03:05 -0600 Subject: 0.9.29, somethings wrong with linker or threading Message-ID: First off, good job with this version, for the most part it is noticably working better than the previous versions. I just ran into a problem with either posix threads (stable) (LINUXTHREADS_OLD=y) or something weird going on with the dynamic linker. A simple file is used for testing purposes called test.c, its contents are only "int main(){}" Using gcc-4.1.2. This works # gcc test.c # ./a.out This does not # gcc -lao test.c # ./a.out # Segfault This does not # gcc -lfuse test.c # ./a.out # Segfault In all two cases above that segfault, directly adding -lpthread fixes the segfault problem. Looks like anything that depends on some library that links to pthread, does not properly recursively link to the pthread (should it?). As noted by the test.c, no threading is directly done there, but if threading is including in a linked library, runtime segfault occurs. Here is the valgrind log for vim: ==18960== ==18960== Stack overflow in thread 1: can't grow stack to 0xBE2EDFFC ==18960== ==18960== Process terminating with default action of signal 11 (SIGSEGV) ==18960== Access not within mapped region at address 0xBE2EDFFC ==18960== at 0x4060BEB: _pthread_cleanup_push_defer (in /lib/libuClibc-0.9.29.so) ==18960== Stack overflow in thread 1: can't grow stack to 0xBE2EDFF8 ==18960== ==18960== Process terminating with default action of signal 11 (SIGSEGV) ==18960== Access not within mapped region at address 0xBE2EDFF8 ==18960== at 0x400A194: _vgnU_freeres (in /tools/lib/valgrind/x86-linux/vgpreload_core.so) The ldd on vim: libncurses.so.6 => /lib/libncurses.so.6 (0xb7f75000) libiconv.so.2 => /lib/libiconv.so.2 (0xb7e97000) libperl.so => //lib/perl5/5.8.8/i686-linux-thread-multi/CORE/libperl.so (0xb7d7d000) libm.so.0 => /lib/libm.so.0 (0xb7d71000) libutil.so.0 => /lib/libutil.so.0 (0xb7d6e000) libc.so.0 => /lib/libc.so.0 (0xb7cdc000) libintl.so.8 => /lib/libintl.so.8 (0xb7cd3000) libtinfo.so.6 => /lib/libtinfo.so.6 (0xb7ca9000) libdl.so.0 => /lib/libdl.so.0 (0xb7ca5000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7c93000) libnsl.so.0 => /lib/libnsl.so.0 (0xb7c91000) libcrypt.so.0 => /lib/libcrypt.so.0 (0xb7c7c000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f94000) An ldd on libperl: checking sub-depends for '/lib/libnsl.so.0' libc.so.0 => /lib/libc.so.0 (0xb7efd000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f93000) checking sub-depends for '/lib/libdl.so.0' libc.so.0 => /lib/libc.so.0 (0xb7e9e000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f34000) checking sub-depends for '/lib/libm.so.0' libc.so.0 => /lib/libc.so.0 (0xb7eba000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f50000) checking sub-depends for '/lib/libcrypt.so.0' libc.so.0 => /lib/libc.so.0 (0xb7ed4000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f6a000) checking sub-depends for '/lib/libutil.so.0' libc.so.0 => /lib/libc.so.0 (0xb7eaa000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f40000) checking sub-depends for '/lib/libpthread.so.0' libc.so.0 => /lib/libc.so.0 (0xb7ee0000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f76000) checking sub-depends for '/lib/libc.so.0' ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7fcc000) checking sub-depends for '/lib/libintl.so.8' libnsl.so.0 => /lib/libnsl.so.0 (0x00000000) libdl.so.0 => /lib/libdl.so.0 (0x00000000) libm.so.0 => /lib/libm.so.0 (0x00000000) libcrypt.so.0 => /lib/libcrypt.so.0 (0x00000000) libutil.so.0 => /lib/libutil.so.0 (0x00000000) libpthread.so.0 => /lib/libpthread.so.0 (0x00000000) libc.so.0 => /lib/libc.so.0 (0x00000000) libintl.so.8 => /lib/libintl.so.8 (0x00000000) not a dynamic executable It looks like the address' were lost during the sub-depends step -- Kevin Day From joakim.tjernlund at transmode.se Mon May 14 23:44:55 2007 From: joakim.tjernlund at transmode.se (Joakim Tjernlund) Date: Tue, 15 May 2007 08:44:55 +0200 Subject: 0.9.29, somethings wrong with linker or threading In-Reply-To: References: Message-ID: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> On Mon, 2007-05-14 at 21:03 -0600, Kevin Day wrote: > First off, good job with this version, for the most part it is > noticably working better than the previous versions. > > I just ran into a problem with either posix threads (stable) > (LINUXTHREADS_OLD=y) or something weird going on with the dynamic > linker. The dynamic linker hasn't received much updates lately, I suspect toolchain. Maybe a if you compile uClibc with SUPPORT_LD_DEBUG=y and run your test app with LD_DEBUG=all ./a.out can tell us more. Jocke > > A simple file is used for testing purposes called test.c, its contents > are only "int main(){}" > Using gcc-4.1.2. > > This works > # gcc test.c > # ./a.out > > This does not > # gcc -lao test.c > # ./a.out > # Segfault > > This does not > # gcc -lfuse test.c > # ./a.out > # Segfault > > In all two cases above that segfault, directly adding -lpthread fixes > the segfault problem. > Looks like anything that depends on some library that links to > pthread, does not properly recursively link to the pthread (should > it?). > As noted by the test.c, no threading is directly done there, but if > threading is including in a linked library, runtime segfault occurs. > > Here is the valgrind log for vim: > > ==18960== > ==18960== Stack overflow in thread 1: can't grow stack to 0xBE2EDFFC > ==18960== > ==18960== Process terminating with default action of signal 11 (SIGSEGV) > ==18960== Access not within mapped region at address 0xBE2EDFFC > ==18960== at 0x4060BEB: _pthread_cleanup_push_defer (in > /lib/libuClibc-0.9.29.so) > ==18960== Stack overflow in thread 1: can't grow stack to 0xBE2EDFF8 > ==18960== > ==18960== Process terminating with default action of signal 11 (SIGSEGV) > ==18960== Access not within mapped region at address 0xBE2EDFF8 > ==18960== at 0x400A194: _vgnU_freeres (in > /tools/lib/valgrind/x86-linux/vgpreload_core.so) > > The ldd on vim: > libncurses.so.6 => /lib/libncurses.so.6 (0xb7f75000) > libiconv.so.2 => /lib/libiconv.so.2 (0xb7e97000) > libperl.so => //lib/perl5/5.8.8/i686-linux-thread-multi/CORE/libperl.so > (0xb7d7d000) > libm.so.0 => /lib/libm.so.0 (0xb7d71000) > libutil.so.0 => /lib/libutil.so.0 (0xb7d6e000) > libc.so.0 => /lib/libc.so.0 (0xb7cdc000) > libintl.so.8 => /lib/libintl.so.8 (0xb7cd3000) > libtinfo.so.6 => /lib/libtinfo.so.6 (0xb7ca9000) > libdl.so.0 => /lib/libdl.so.0 (0xb7ca5000) > libpthread.so.0 => /lib/libpthread.so.0 (0xb7c93000) > libnsl.so.0 => /lib/libnsl.so.0 (0xb7c91000) > libcrypt.so.0 => /lib/libcrypt.so.0 (0xb7c7c000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f94000) > > An ldd on libperl: > checking sub-depends for '/lib/libnsl.so.0' > libc.so.0 => /lib/libc.so.0 (0xb7efd000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f93000) > checking sub-depends for '/lib/libdl.so.0' > libc.so.0 => /lib/libc.so.0 (0xb7e9e000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f34000) > checking sub-depends for '/lib/libm.so.0' > libc.so.0 => /lib/libc.so.0 (0xb7eba000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f50000) > checking sub-depends for '/lib/libcrypt.so.0' > libc.so.0 => /lib/libc.so.0 (0xb7ed4000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f6a000) > checking sub-depends for '/lib/libutil.so.0' > libc.so.0 => /lib/libc.so.0 (0xb7eaa000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f40000) > checking sub-depends for '/lib/libpthread.so.0' > libc.so.0 => /lib/libc.so.0 (0xb7ee0000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f76000) > checking sub-depends for '/lib/libc.so.0' > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7fcc000) > checking sub-depends for '/lib/libintl.so.8' > libnsl.so.0 => /lib/libnsl.so.0 (0x00000000) > libdl.so.0 => /lib/libdl.so.0 (0x00000000) > libm.so.0 => /lib/libm.so.0 (0x00000000) > libcrypt.so.0 => /lib/libcrypt.so.0 (0x00000000) > libutil.so.0 => /lib/libutil.so.0 (0x00000000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00000000) > libc.so.0 => /lib/libc.so.0 (0x00000000) > libintl.so.8 => /lib/libintl.so.8 (0x00000000) > not a dynamic executable > > It looks like the address' were lost during the sub-depends step > From thekevinday at gmail.com Tue May 15 08:51:01 2007 From: thekevinday at gmail.com (Kevin Day) Date: Tue, 15 May 2007 09:51:01 -0600 Subject: 0.9.29, somethings wrong with linker or threading In-Reply-To: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> References: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> Message-ID: On 5/15/07, Joakim Tjernlund wrote: > On Mon, 2007-05-14 at 21:03 -0600, Kevin Day wrote: > > First off, good job with this version, for the most part it is > > noticably working better than the previous versions. > > > > I just ran into a problem with either posix threads (stable) > > (LINUXTHREADS_OLD=y) or something weird going on with the dynamic > > linker. > > The dynamic linker hasn't received much updates lately, I suspect > toolchain. Maybe a if you compile uClibc with SUPPORT_LD_DEBUG=y > and run your test app with > LD_DEBUG=all ./a.out > can tell us more. > I started a fresh build and set all debug options on. However, before I can get to re-testing this problem, turning the debug options on caused some new problems. while compiling gcc, the following occurs "error: storage size of 'dostat' is unknown" looking into , should 'struct stat' be 'typedef struct stat' ? I suspect this error is being generated due to the SUPPORT_LD_DEBUG_EARLY, so i am going to disable that and try again. -- Kevin Day From thekevinday at gmail.com Tue May 15 17:27:04 2007 From: thekevinday at gmail.com (Kevin Day) Date: Tue, 15 May 2007 18:27:04 -0600 Subject: 0.9.29, somethings wrong with linker or threading In-Reply-To: References: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> Message-ID: On 5/15/07, Kevin Day wrote: > On 5/15/07, Joakim Tjernlund wrote: > > On Mon, 2007-05-14 at 21:03 -0600, Kevin Day wrote: > > > First off, good job with this version, for the most part it is > > > noticably working better than the previous versions. > > > > > > I just ran into a problem with either posix threads (stable) > > > (LINUXTHREADS_OLD=y) or something weird going on with the dynamic > > > linker. > > > > The dynamic linker hasn't received much updates lately, I suspect > > toolchain. Maybe a if you compile uClibc with SUPPORT_LD_DEBUG=y > > and run your test app with > > LD_DEBUG=all ./a.out > > can tell us more. > > > okay, with all debug optiosn except LD_DEBUG_EARLY, things compiled as they did before. Now that I have a debuggability, I performed two tests. I used perl for my tests as it also produces the same errors and..well just about all things using pthread. first was 'gcc -lperl -lpthread test.c' i then logged 'LD_DEBUG=all ./a.out' the second was 'gcc -lperl test.c' i then logged 'LD_DEBUG=all ./a.out' To see what is going on differently between the two, I made a diff of the two logs. I called it log.patch so vim would use syntax highlighting (.patch extension). The diff of the two tests is attached. -- Kevin Day -------------- next part -------------- A non-text attachment was scrubbed... Name: log.patch Type: application/octet-stream Size: 11327 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20070515/a9c5b5e9/attachment.obj From rob at landley.net Tue May 15 21:53:58 2007 From: rob at landley.net (Rob Landley) Date: Wed, 16 May 2007 00:53:58 -0400 Subject: threads and libc/stdlib/malloc In-Reply-To: <200705122306.27039.rgetz@blackfin.uclinux.org> References: <200705122306.27039.rgetz@blackfin.uclinux.org> Message-ID: <200705160053.58837.rob@landley.net> On Saturday 12 May 2007 11:06 pm, Robin Getz wrote: > * Add support for uClinux's broken munmap, contingent on > __UCLIBC_UCLINUX_BROKEN_MUNMAP__ (which is currently not defined anywhere). > This makes other cases a tiny bit less efficient too. You might want to ask on the uClinux mailing lists, as they're more likely to know about nommu historical issues than the uClibc guys. It sounds like historical cruft, but I can't confirm what specifically did or didn't need it. Rob From joakim.tjernlund at transmode.se Wed May 16 01:12:29 2007 From: joakim.tjernlund at transmode.se (Joakim Tjernlund) Date: Wed, 16 May 2007 10:12:29 +0200 Subject: 0.9.29, somethings wrong with linker or threading In-Reply-To: References: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> Message-ID: <1179303149.11624.10.camel@gentoo-jocke.transmode.se> On Tue, 2007-05-15 at 18:27 -0600, Kevin Day wrote: > On 5/15/07, Kevin Day wrote: > > On 5/15/07, Joakim Tjernlund wrote: > > > On Mon, 2007-05-14 at 21:03 -0600, Kevin Day wrote: > > > > First off, good job with this version, for the most part it is > > > > noticably working better than the previous versions. > > > > > > > > I just ran into a problem with either posix threads (stable) > > > > (LINUXTHREADS_OLD=y) or something weird going on with the dynamic > > > > linker. > > > > > > The dynamic linker hasn't received much updates lately, I suspect > > > toolchain. Maybe a if you compile uClibc with SUPPORT_LD_DEBUG=y > > > and run your test app with > > > LD_DEBUG=all ./a.out > > > can tell us more. > > > > > > okay, with all debug optiosn except LD_DEBUG_EARLY, things compiled as > they did before. > > Now that I have a debuggability, I performed two tests. > I used perl for my tests as it also produces the same errors and..well > just about all things using pthread. > first was 'gcc -lperl -lpthread test.c' > i then logged 'LD_DEBUG=all ./a.out' > > the second was 'gcc -lperl test.c' > i then logged 'LD_DEBUG=all ./a.out' > > To see what is going on differently between the two, I made a diff of > the two logs. > I called it log.patch so vim would use syntax highlighting (.patch extension). > > The diff of the two tests is attached. > Its a bit hard to make out what is going on from a diff only, but it appears that the INIT processing in libpthread is SEGV, but only if libpthread is loadead after libc. Perhaps commenting stuff out in pthread_initialize() will pinpoint the error. Maybe it is an uncommon CONFIG option thats causing it(LOCALE?) Jocke From joakim.tjernlund at transmode.se Wed May 16 10:06:59 2007 From: joakim.tjernlund at transmode.se (Joakim Tjernlund) Date: Wed, 16 May 2007 19:06:59 +0200 Subject: 0.9.29, somethings wrong with linker or threading In-Reply-To: References: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> <1179303149.11624.10.camel@gentoo-jocke.transmode.se> Message-ID: <1179335219.2714.12.camel@gentoo-jocke.transmode.se> On Wed, 2007-05-16 at 08:32 -0600, Kevin Day wrote: > On 5/16/07, Joakim Tjernlund wrote: > > On Tue, 2007-05-15 at 18:27 -0600, Kevin Day wrote: > > > okay, with all debug optiosn except LD_DEBUG_EARLY, things compiled as > > > they did before. > > > > > > Now that I have a debuggability, I performed two tests. > > > I used perl for my tests as it also produces the same errors and..well > > > just about all things using pthread. > > > first was 'gcc -lperl -lpthread test.c' > > > i then logged 'LD_DEBUG=all ./a.out' > > > > > > the second was 'gcc -lperl test.c' > > > i then logged 'LD_DEBUG=all ./a.out' > > > > > > To see what is going on differently between the two, I made a diff of > > > the two logs. > > > I called it log.patch so vim would use syntax highlighting (.patch extension). > > > > > > The diff of the two tests is attached. > > > > > > > Its a bit hard to make out what is going on from a diff only, but it > > appears that the INIT processing in libpthread is SEGV, but only if > > libpthread is loadead after libc. Perhaps commenting stuff out > > in pthread_initialize() will pinpoint the error. > > Maybe it is an uncommon CONFIG option thats causing it(LOCALE?) > > > > Jocke > > > > > > > > I constantly worry about size limitations, but here is my config and > the complete segfaulting log > > I will look into pthread_initialize. > locale is enabled Try turning locale off. > > What i am seeing on the patch is that the non-segfaulting version > calls _dl_get_ready_to_run:814: calling INIT: /lib/libintl.so.8 before > libpthread. Can you post can the other log too? > > Another thing that sticks out to me is that "_dl_fixup:664: relocation > processing: /lib/libpthread.so.0" happends in the non-segfaulting one, > but does appear in the segfaulting one. ? something is missing here. That message is present in both cases. > > And finally there is the part you mentioned about pthread. > > Those things stood out to me in the diff, i will look into commenting > out pthread_initialize() Start with commenting out locale stuff and then stdio Jocke From thekevinday at gmail.com Wed May 16 07:32:41 2007 From: thekevinday at gmail.com (Kevin Day) Date: Wed, 16 May 2007 08:32:41 -0600 Subject: 0.9.29, somethings wrong with linker or threading In-Reply-To: <1179303149.11624.10.camel@gentoo-jocke.transmode.se> References: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> <1179303149.11624.10.camel@gentoo-jocke.transmode.se> Message-ID: On 5/16/07, Joakim Tjernlund wrote: > On Tue, 2007-05-15 at 18:27 -0600, Kevin Day wrote: > > okay, with all debug optiosn except LD_DEBUG_EARLY, things compiled as > > they did before. > > > > Now that I have a debuggability, I performed two tests. > > I used perl for my tests as it also produces the same errors and..well > > just about all things using pthread. > > first was 'gcc -lperl -lpthread test.c' > > i then logged 'LD_DEBUG=all ./a.out' > > > > the second was 'gcc -lperl test.c' > > i then logged 'LD_DEBUG=all ./a.out' > > > > To see what is going on differently between the two, I made a diff of > > the two logs. > > I called it log.patch so vim would use syntax highlighting (.patch extension). > > > > The diff of the two tests is attached. > > > > Its a bit hard to make out what is going on from a diff only, but it > appears that the INIT processing in libpthread is SEGV, but only if > libpthread is loadead after libc. Perhaps commenting stuff out > in pthread_initialize() will pinpoint the error. > Maybe it is an uncommon CONFIG option thats causing it(LOCALE?) > > Jocke > > > I constantly worry about size limitations, but here is my config and the complete segfaulting log I will look into pthread_initialize. locale is enabled What i am seeing on the patch is that the non-segfaulting version calls _dl_get_ready_to_run:814: calling INIT: /lib/libintl.so.8 before libpthread. Another thing that sticks out to me is that "_dl_fixup:664: relocation processing: /lib/libpthread.so.0" happends in the non-segfaulting one, but does appear in the segfaulting one. And finally there is the part you mentioned about pthread. Those things stood out to me in the diff, i will look into commenting out pthread_initialize() -- Kevin Day -------------- next part -------------- A non-text attachment was scrubbed... Name: uc.conf Type: application/octet-stream Size: 4902 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20070516/53250eae/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: log Type: application/octet-stream Size: 8541 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20070516/53250eae/attachment-0001.obj From thekevinday at gmail.com Wed May 16 12:37:12 2007 From: thekevinday at gmail.com (Kevin Day) Date: Wed, 16 May 2007 13:37:12 -0600 Subject: 0.9.29, somethings wrong with linker or threading In-Reply-To: <1179335219.2714.12.camel@gentoo-jocke.transmode.se> References: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> <1179303149.11624.10.camel@gentoo-jocke.transmode.se> <1179335219.2714.12.camel@gentoo-jocke.transmode.se> Message-ID: On 5/16/07, Joakim Tjernlund wrote: > On Wed, 2007-05-16 at 08:32 -0600, Kevin Day wrote: > > On 5/16/07, Joakim Tjernlund wrote: > > > On Tue, 2007-05-15 at 18:27 -0600, Kevin Day wrote: > > > > okay, with all debug optiosn except LD_DEBUG_EARLY, things compiled as > > > > they did before. > > > > > > > > Now that I have a debuggability, I performed two tests. > > > > I used perl for my tests as it also produces the same errors and..well > > > > just about all things using pthread. > > > > first was 'gcc -lperl -lpthread test.c' > > > > i then logged 'LD_DEBUG=all ./a.out' > > > > > > > > the second was 'gcc -lperl test.c' > > > > i then logged 'LD_DEBUG=all ./a.out' > > > > > > > > To see what is going on differently between the two, I made a diff of > > > > the two logs. > > > > I called it log.patch so vim would use syntax highlighting (.patch extension). > > > > > > > > The diff of the two tests is attached. > > > > > > > > > > Its a bit hard to make out what is going on from a diff only, but it > > > appears that the INIT processing in libpthread is SEGV, but only if > > > libpthread is loadead after libc. Perhaps commenting stuff out > > > in pthread_initialize() will pinpoint the error. > > > Maybe it is an uncommon CONFIG option thats causing it(LOCALE?) > > > > > > Jocke > > > > > > > > > > > > > I constantly worry about size limitations, but here is my config and > > the complete segfaulting log > > > > I will look into pthread_initialize. > > locale is enabled > > Try turning locale off. > > > > > What i am seeing on the patch is that the non-segfaulting version > > calls _dl_get_ready_to_run:814: calling INIT: /lib/libintl.so.8 before > > libpthread. > > Can you post can the other log too? You already have it, in a manner of speaking. put the complete segfaulting log I gave you, and the diff in the same directory use patch for the diff of the logs, 'patch -Np0 -i log.patch' This will give you the complete log for the non-segfaulting version > > > > > Another thing that sticks out to me is that "_dl_fixup:664: relocation > > processing: /lib/libpthread.so.0" happends in the non-segfaulting one, > > but does appear in the segfaulting one. > ? something is missing here. That message is present in both cases. Are you familiar with diff files? In diff files, there is a first character for each line a space ' ' means no change a minus '-' means remove this a plus '+' means add this when the diff file contains only a '+' and is not followed by or preceded by a relating '-', then this means that there is something completely different. Just in case you are in fact not familair with diff and do not have the patch command, I will attach the other log anyway. > > > > > And finally there is the part you mentioned about pthread. > > > > Those things stood out to me in the diff, i will look into commenting > > out pthread_initialize() > > Start with commenting out locale stuff and then stdio > > Jocke > I am working on getting the locale off, but I will again have to completely build a new system in part due to the new build system depending on, which is then linked to locale, so I cannot. First I will build a system only disabling locale via the uclibc.config options and after that is logged, directly start commenting out code, which should hopefully be only stdio code at that point due to locale no longer being built. -- Kevin Day -------------- next part -------------- A non-text attachment was scrubbed... Name: working_log Type: application/octet-stream Size: 8952 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20070516/72e9be76/attachment-0001.obj From thekevinday at gmail.com Wed May 16 17:07:09 2007 From: thekevinday at gmail.com (Kevin Day) Date: Wed, 16 May 2007 18:07:09 -0600 Subject: 0.9.29, somethings wrong with linker or threading In-Reply-To: References: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> <1179303149.11624.10.camel@gentoo-jocke.transmode.se> <1179335219.2714.12.camel@gentoo-jocke.transmode.se> Message-ID: I'd send the logs, but these are too big, what format should i compress them into? I can do 7z, lzop, bzip2, and gzip. Still the same problem, so it rules out locale. It also looks like I must have used LD_DEBUG=yes on the last two logs as these two I have are significantly bigger. The each of the logs is about 400k, and the list will only accept 40k.. From carmelo73 at gmail.com Wed May 16 22:43:45 2007 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Thu, 17 May 2007 07:43:45 +0200 Subject: 0.9.29, somethings wrong with linker or threading In-Reply-To: References: <1179211496.20638.110.camel@gentoo-jocke.transmode.se> <1179303149.11624.10.camel@gentoo-jocke.transmode.se> <1179335219.2714.12.camel@gentoo-jocke.transmode.se> Message-ID: <2ccd6e3c0705162243t1137b3b3r69ed46c82a984b4b@mail.gmail.com> > Are you familiar with diff files? > > In diff files, there is a first character for each line > a space ' ' means no change > a minus '-' means remove this > a plus '+' means add this > > when the diff file contains only a '+' and is not followed by or > preceded by a relating '-', then this means that there is something > completely different. > > Just in case you are in fact not familair with diff and do not have > the patch command, I will attach the other log anyway. > Do you need some helps to solve your problem.... or do you want to take a training on diff and patch? I don't think Jocke needs.... so please, keep this comment out of this list.... patch and diff are our daily work. Thanks and regards, Carmelo From fernando at elec.gla.ac.uk Thu May 17 06:38:29 2007 From: fernando at elec.gla.ac.uk (Fernando Rodriguez) Date: Thu, 17 May 2007 14:38:29 +0100 Subject: sendto: Invalid argument Message-ID: <464C5AD5.7030907@elec.gla.ac.uk> I am using a frsh compile of uclibc (compiled from buildroot using svn for at91 ARM architecture). Regardless of whether I use the dailiy snapshot of uclibc or version 0.9.29 I get this behaviour in the target: # ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes ping: sendto: Invalid argument This is not specific to ping. If I do: # udhcpc eth0 udhcpc (v1.5.0) started eth0: Link now 100-FullDuplex Sending discover... udhcpc: sendto: Invalid argument Sending discover... udhcpc: sendto: Invalid argument I get the same result. Please note that the loopback interface is properly set, and that I can actually manually setup eth0 and ping the interface from the outside with no problems. Also, note that the loopback interface is properly (or am I missing something?) setup: # ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.0 * 255.0.0.0 U 0 0 0 lo # I would appreciate any help. As additional information, here is a copy of my boot messages: Linux version 2.6.14-uc0 (Alan at buffy) (gcc version 3.3.2) #4 Thu May 17 12:19:44 BST 2007 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) Machine: Artila Matrix500V2 Memory policy: ECC disabled, Data cache writeback Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz On node 0 totalpages: 8192 DMA zone: 8192 pages, LIFO batch:3 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Built 1 zonelists Kernel command line: mem=32M console=ttyS0,115200 initrd=0x20800000,8192000 ramdisk_size=15360 root=/dev/ram0 rw mtdparts=phys_mapped_flash:128k(loader)ro,128k(env)ro,1408k(linux)ro,2560k(ramdisk)ro,-(userdisk) AT91: 128 gpio irqs in 4 banks PID hash table entries: 256 (order: 8, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 32MB = 32MB total Memory: 21436KB available (2269K code, 536K data, 104K init) Calibrating delay loop... 89.70 BogoMIPS (lpj=448512) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 8000K NET: Registered protocol family 16 Generic PHY: Registered new driver SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub NetWinder Floating Point Emulator V0.97 (extended precision) JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. Initializing Cryptographic API Matrix500 RTC driver. Matrix500 GPIO Driver Loaded. AT91 SPI driver loaded AT91 Watchdog Timer enabled (5 seconds) ttyS0 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL ttyS1 at MMIO 0xfefc0000 (irq = 6) is a AT91_SERIAL ttyS2 at MMIO 0xfefc4000 (irq = 7) is a AT91_SERIAL ttyS3 at MMIO 0xfefc8000 (irq = 8) is a AT91_SERIAL ttyS4 at MMIO 0xfefcc000 (irq = 9) is a AT91_SERIAL io scheduler noop registered io scheduler anticipatory registered RAMDISK driver initialized: 16 RAM disks of 15360K size 1024 blocksize Davicom DM9161E: Registered new driver Davicom DM9131: Registered new driver PPP generic driver version 2.4.2 PPP BSD Compression module registered NET: Registered protocol family 24 eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:13:48:00:15:c7) eth0: Davicom 9161AE PHY (Copper) physmap flash device: 1000000 at 10000000 phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x010A Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled 0: offset=0x0,size=0x20000,blocks=127 1: offset=0xfe0000,size=0x8000,blocks=4 5 cmdlinepart partitions found on MTD device phys_mapped_flash Creating 5 MTD partitions on "phys_mapped_flash": 0x00000000-0x00020000 : "loader" 0x00020000-0x00040000 : "env" 0x00040000-0x001a0000 : "linux" 0x001a0000-0x00420000 : "ramdisk" 0x00420000-0x01000000 : "userdisk" block2mtd: version $Revision: 1.28 $ at91rm9200-ohci at91rm9200-ohci: starting AT91RM9200 OHCI USB Controller at91rm9200-ohci at91rm9200-ohci: AT91RM9200 OHCI at91rm9200-ohci at91rm9200-ohci: new USB bus registered, assigned bus number 1 at91rm9200-ohci at91rm9200-ohci: irq 23, io mem 0x00300000 at91rm9200-ohci at91rm9200-ohci: resetting from state 'reset', control = 0x0 at91rm9200-ohci at91rm9200-ohci: OHCI controller state at91rm9200-ohci at91rm9200-ohci: OHCI 1.0, NO legacy support registers at91rm9200-ohci at91rm9200-ohci: control 0x083 HCFS=operational CBSR=3 at91rm9200-ohci at91rm9200-ohci: cmdstatus 0x00000 SOC=0 at91rm9200-ohci at91rm9200-ohci: intrstatus 0x00000044 RHSC SF at91rm9200-ohci at91rm9200-ohci: intrenable 0x8000001a MIE UE RD WDH at91rm9200-ohci at91rm9200-ohci: fminterval a7782edf at91rm9200-ohci at91rm9200-ohci: hcca frame #0005 at91rm9200-ohci at91rm9200-ohci: roothub.a 02000202 POTPGT=2 NPS NDP=2(2) at91rm9200-ohci at91rm9200-ohci: roothub.b 00000000 PPCM=0000 DR=0000 at91rm9200-ohci at91rm9200-ohci: roothub.status 00008000 DRWE at91rm9200-ohci at91rm9200-ohci: roothub.portstatus [0] 0x00000100 PPS at91rm9200-ohci at91rm9200-ohci: roothub.portstatus [1] 0x00000100 PPS at91rm9200-ohci at91rm9200-ohci: created debug files usb usb1: default language 0x0409 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: AT91RM9200 OHCI usb usb1: Manufacturer: Linux 2.6.14-uc0 ohci_hcd usb usb1: SerialNumber: at91rm9200 usb usb1: hotplug usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: hotplug hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: no power switching (usb 1.0) hub 1-0:1.0: global over-current protection hub 1-0:1.0: power on to power good time: 4ms hub 1-0:1.0: local power source is good hub 1-0:1.0: no over-current condition exists hub 1-0:1.0: state 5 ports 2 chg 0000 evt 0000 usbcore: registered new driver cdc_acm drivers/usb/class/cdc-acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. usbcore: registered new driver rtusb usbcore: registered new driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic usbcore: registered new driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0 drivers/usb/serial/usb-serial.c: USB Serial support registered for PL-2303 usbcore: registered new driver pl2303 drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.12 udc: at91_udc version 8 March 2005 mice: PS/2 mouse device common for all mice i2c /dev entries driver Found AT91 i2c RTC found. EEPROM found. AT91RM9200 MCI initialized NET: Registered protocol family 2 IP route cache hash table entries: 512 (order: -1, 2048 bytes) TCP established hash table entries: 2048 (order: 1, 8192 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered ip_conntrack version 2.3 (256 buckets, 2048 max) - 220 bytes per conntrack ctnetlink v0.90: registering with nfnetlink. ip_tables: (C) 2000-2002 Netfilter core team arp_tables: (C) 2002 David S. Miller TCP bic registered Netfilter messages via NETLINK v0.30. NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 RAMDISK: