Re: Error in _atexit.c building mips/mipsel.
On Sun, Sep 28, 2008 at 11:58:02AM -0500, Rob Landley wrote: Tracking this one down, but it still happens in last night's svn... In file included from libc/stdlib/__cxa_finalize.c:8: libc/stdlib/_atexit.c: In function '__cxa_finalize': libc/stdlib/_atexit.c:205: warning: implicit declaration of function 'typeof' done. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: LINUXTHREADS_NEW bug.
On Mon, 29 Sep 2008 10:02:18 +0200 Bernhard Reutner-Fischer [EMAIL PROTECTED] wrote: On Sun, Sep 28, 2008 at 07:55:24PM -0500, Rob Landley wrote: snipp Would anyone like to comment on this? not really. I already said that we will not remove linuxthreads.old for 0.9.30 because removing it right now doesn't make sense. I also said that linuxthreads.new should at least work for i386 before we remove the .old. 'Nuff said, tested patches welcome. Well, AVR32 uses linuxthreads.old, since linuxthreads does not seem to work. I have not looked into why. AVR32 is not ready to support NPTL yet, although it is there on the stuff TODO. Hopefully AVR32 will be ready to switch to NPTL for uClibc 0.9.31 or whatever will be the next release. I suggest we only wipe a thread library when all architecture have a working alternative, hopefully NPTL. -- Best regards, Hans-Christian Egtvedt ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: PATCH: disable LINUXTHREADS_OLD in menuconfig.
On Sat, 27 Sep 2008 16:57:20 -0500 Rob Landley [EMAIL PROTECTED] wrote: I'd like to apply the following small patch as a start on at least deprecating the hell out of LINUXTHREADS_OLD. All it does is stop it showing up in menuconfig, and make the symbol default to n. We really do need to get down to one pthreads implementation before we start adding nptl-threads, and getting the new we have a better chance of maintaining actually widely tested is an important part of that. Comments? It will remove threads support for AVR32 architecture, so I would say no to apply it. I agree that we should aim for all architectures to have NPTL, but only after all the architectures actually are working with this thread library IMHO. -- Best regards, Hans-Christian Egtvedt ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: LINUXTHREADS_NEW bug.
On Mon, Sep 29, 2008 at 1:00 PM, Hans-Christian Egtvedt [EMAIL PROTECTED] wrote: On Mon, 29 Sep 2008 07:36:53 -0400 John Voltz [EMAIL PROTECTED] wrote: Well, AVR32 uses linuxthreads.old, since linuxthreads does not seem to work. I have not looked into why. I thought AVR32 didn't have tls.h for linuxthreads, which causes the build to fail. (If I remember correctly.) Ah, in that case it explains why it does not work. We would need tls (I assume it is thread local storage) to move to NPTL as well, but binutils will need a whack then. And we might need to go through all AVR32 assembler stuff in uClibc and the kernel as well. It should be possible to use an empty header for tls.h if TLS is not supported by the toolchain. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
[MIPS] syscall() segv on mips1
Hi, uclibc trunk on mips1 platform, a failed syscall() crashes later in __syscall_error() from incorrect t9 value. syscall() has .noreorder, so I guess this explicit 'nop' is needed. --- libc/sysdeps/linux/mips/syscall.S.orig 2008-09-29 15:59:31.0 +0200 +++ libc/sysdeps/linux/mips/syscall.S 2008-09-29 15:59:40.0 +0200 @@ -73,6 +73,7 @@ SETUP_GP64(v0, syscall) PTR_LA t9, __syscall_error RESTORE_GP64 + nop jr t9 #else j __syscall_error -- Maxime ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Internal compiler error building m68k.
On Sun, Sep 28, 2008 at 11:55:53AM -0500, Rob Landley wrote: So with the attached .config, building last night's svn snapshot, is anybody else seeing this: libc/inet/addr.c: In function 'inet_ntoa_r': libc/inet/addr.c:144: internal compiler error: in output_move_qimode, at config/m68k/m68k.c:1827 Seems to work for me with the current, stable release of gcc. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: PATCH: disable LINUXTHREADS_OLD in menuconfig.
On Mon, Sep 29, 2008 at 02:36:32PM +0200, Hans-Christian Egtvedt wrote: On Sat, 27 Sep 2008 16:57:20 -0500 Rob Landley [EMAIL PROTECTED] wrote: I'd like to apply the following small patch as a start on at least deprecating the hell out of LINUXTHREADS_OLD. All it does is stop it showing up in menuconfig, and make the symbol default to n. We really do need to get down to one pthreads implementation before we start adding nptl-threads, and getting the new we have a better chance of maintaining actually widely tested is an important part of that. Comments? It will remove threads support for AVR32 architecture, so I would say no to apply it. I agree that we should aim for all architectures to have NPTL, but only after all the architectures actually are working with this thread library IMHO. agree. Rob, if you want to deprecate linuxthreads.old after the 0.9.30 release then please go to the NPTL branch and add support for i386, powerpc, m68k etc, etc either against nptl or linuxthreads.new. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [MIPS] syscall() segv on mips1
uclibc trunk on mips1 platform, a failed syscall() crashes later in __syscall_error() from incorrect t9 value. syscall() has .noreorder, so I guess this explicit 'nop' is needed. --- libc/sysdeps/linux/mips/syscall.S.orig2008-09-29 15:59:31.0 +0200 +++ libc/sysdeps/linux/mips/syscall.S 2008-09-29 15:59:40.0 +0200 @@ -73,6 +73,7 @@ SETUP_GP64(v0, syscall) PTR_LA t9, __syscall_error RESTORE_GP64 + nop jr t9 #else j __syscall_error Would you kindly do an 'objdump -d' on your 'syscall.o' file and send it to me? Your patch is probably fine, by I want to see your generated assembly code. Thanks. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [MIPS] syscall() segv on mips1
On Mon, 2008-09-29 at 10:36 -0500, [EMAIL PROTECTED] wrote: Would you kindly do an 'objdump -d' on your 'syscall.o' file and send it to me? Your patch is probably fine, by I want to see your generated assembly code. Thanks. syscall.os: file format elf32-tradbigmips Disassembly of section .text: syscall: 0: 3c1clui gp,0x0 4: 279caddiu gp,gp,0 8: 0399e021addugp,gp,t9 c: 00801021movev0,a0 10: 00a02021movea0,a1 14: 00c02821movea1,a2 18: 00e03021movea2,a3 1c: 8fa70010lw a3,16(sp) 20: 8fa80014lw t0,20(sp) 24: 8fa90018lw t1,24(sp) 28: 8faa001clw t2,28(sp) 2c: 27bdffe0addiu sp,sp,-32 30: afa80010sw t0,16(sp) 34: afa90014sw t1,20(sp) 38: afaa0018sw t2,24(sp) 3c: afa2001csw v0,28(sp) 40: 8fa2001clw v0,28(sp) 44: 000csyscall 48: 14e2bneza3,54 syscall+0x54 4c: 27bd0020addiu sp,sp,32 50: 03e8jr ra 54: 00402021movea0,v0 58: 8f99lw t9,0(gp) 5c: nop 60: 0328jr t9 64: nop ... -- Maxime ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Internal compiler error building m68k.
On Monday 29 September 2008 10:56:04 Bernhard Reutner-Fischer wrote: On Sun, Sep 28, 2008 at 11:55:53AM -0500, Rob Landley wrote: So with the attached .config, building last night's svn snapshot, is anybody else seeing this: libc/inet/addr.c: In function 'inet_ntoa_r': libc/inet/addr.c:144: internal compiler error: in output_move_qimode, at config/m68k/m68k.c:1827 Seems to work for me with the current, stable release of gcc. I tried 4.1.2 and 4.2.2. You seem to be saying that uClibc for m68k is not supported on those. Rob ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: PATCH: disable LINUXTHREADS_OLD in menuconfig.
On Monday 29 September 2008 11:04:27 Bernhard Reutner-Fischer wrote: On Mon, Sep 29, 2008 at 02:36:32PM +0200, Hans-Christian Egtvedt wrote: On Sat, 27 Sep 2008 16:57:20 -0500 Rob Landley [EMAIL PROTECTED] wrote: I'd like to apply the following small patch as a start on at least deprecating the hell out of LINUXTHREADS_OLD. All it does is stop it showing up in menuconfig, and make the symbol default to n. We really do need to get down to one pthreads implementation before we start adding nptl-threads, and getting the new we have a better chance of maintaining actually widely tested is an important part of that. Comments? It will remove threads support for AVR32 architecture, so I would say no to apply it. I agree that we should aim for all architectures to have NPTL, but only after all the architectures actually are working with this thread library IMHO. agree. Rob, if you want to deprecate linuxthreads.old after the 0.9.30 release then please go to the NPTL branch and add support for i386, powerpc, m68k etc, etc either against nptl or linuxthreads.new. I think you're confusing NPTL with linxthreads.new. I'm happy to push for deprecating linuxthreads.new if nobody's ever used it that has a better chance of success. Neither pthreads implementation is NPTL or has anything to do with other SVN forks, I don't know why people keep confusing 'em... Rob ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
