From michael at talamasca.ocis.net Wed Jan 2 22:22:57 2008 From: michael at talamasca.ocis.net (Michael Deutschmann) Date: Wed, 2 Jan 2008 22:22:57 -0800 (PST) Subject: Linux 2.0 troglodyte signing in Message-ID: <%y4HfHl9MU@khar-pern.talamasca.ocis.net> Hello, mailing list! Normally introduction posts are unnecessary in technical forums, but I felt I should say something since my intended use of uClibc is a little eccentric. You may remember waaaay back with Linux 2.2.0 came out, there were some cautions that the new kernel was a little bloated and maybe less stable, so for the moment it might be a good idea for slower machines to stick with 2.0.x for a while. I run a do-it-yourself GNU/Linux on old "toaster" computers, so I followed that advice. But, since then my impression of the stability of current versions of Linux has gone *down*, not *up*. So I continue to run 2.0 to this day. (It's also become something of a game to me, now...) There are some challenges, however. Current versions of GLIBC demand a current kernel, and current versions of GCC want a current GLIBC. So I'm stranded at glibc-2.1.3 and gcc-2.95.3. The latest versions of other applications usually compile, but sometimes patching is needed. Compounding this, I'm proud of my ability to cram all my root executables onto just two bootable floppies, without resorting to busybox. The binaries on my recovery disks are the same ones I use day-to-day. But the space margin is getting thin, and a current kernel and glibc would blow it away. uClibc offers me a way to solve both problems. It gives me back over 600k of rootdisk space (before compression) while offering better source compatibility than my ancient glibc. While uClibc is advertised as supporting Linux 2.0, I did encounter a number of serious bugs. But I found them easy to fix, and now have a prototype system running Linux-2.0.40 / uClibc-0.9.29 / gcc-4.2.2 which is fully self-hosted and working well. If the screaming about how crazy I am isn't too loud ;-), I'll probably send most of my changes to the bug-report system soon. Don't worry, most of my patches are very small and some resolve bugs that are not specific to old kernels. ---- Michael Deutschmann From lane at brooks.nu Fri Jan 4 11:00:29 2008 From: lane at brooks.nu (Lane Brooks) Date: Fri, 04 Jan 2008 12:00:29 -0700 Subject: unresolved symbols with locale support Message-ID: <477E824D.6000700@brooks.nu> I recently turned on locale support in my uclibc build, and after recompiling everything, I am getting the following unresolved symbols when trying to run commands like python: python: symbol '__ctype_b': can't resolve symbol in lib 'python' I am new to locale support and am unsure how to hunt this problem down. I see that __ctype_b_loc is now defined. So is the problem with python or uclibc? Things were working fine for me before turning on locale support, but it seems I need locale support to compile xorg/gtk. Thanks, Lane Brooks From lane at brooks.nu Fri Jan 4 19:37:07 2008 From: lane at brooks.nu (Lane Brooks) Date: Fri, 04 Jan 2008 20:37:07 -0700 Subject: unresolved symbols with locale support In-Reply-To: <477E824D.6000700@brooks.nu> References: <477E824D.6000700@brooks.nu> Message-ID: <477EFB63.3010403@brooks.nu> I found my problem. It was stale binaries did not get installed correctly. Lane Lane Brooks wrote: > I recently turned on locale support in my uclibc build, and after > recompiling everything, I am getting the following unresolved symbols > when trying to run commands like python: > > python: symbol '__ctype_b': can't resolve symbol in lib 'python' > > I am new to locale support and am unsure how to hunt this problem down. > > I see that __ctype_b_loc is now defined. So is the problem with python > or uclibc? > > Things were working fine for me before turning on locale support, but it > seems I need locale support to compile xorg/gtk. > > Thanks, > Lane Brooks > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From vapier at gentoo.org Fri Jan 4 23:45:57 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 02:45:57 -0500 Subject: [PATCH 0/7] AVR32 support for uClibc In-Reply-To: <473C0484.8070501@atmel.com> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <473C0484.8070501@atmel.com> Message-ID: <200801050245.58419.vapier@gentoo.org> On Thursday 15 November 2007, Hans-Christian Egtvedt wrote: > Should I apply for commit access to Subversion in order to maintain the > AVR32 architecture? that would be sanest since you two know AVR and no one else does. please send me private e-mails with your desired username and pub ssh key. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/876dad87/attachment.pgp From vapier at gentoo.org Fri Jan 4 23:47:06 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 02:47:06 -0500 Subject: [PATCH 0/7] AVR32 support for uClibc In-Reply-To: <11943354102834-git-send-email-hcegtvedt@atmel.com> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> Message-ID: <200801050247.06828.vapier@gentoo.org> On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > stopped by mailman since it attached more than 40 kB. side note: ive upped the ante to 100 kB. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/59807739/attachment.pgp From vapier at gentoo.org Fri Jan 4 23:51:23 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 02:51:23 -0500 Subject: [PATCH 2/7] add include, bits and sys headers In-Reply-To: <1194335410428-git-send-email-hcegtvedt@atmel.com> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354103911-git-send-email-hcegtvedt@atmel.com> <1194335410428-git-send-email-hcegtvedt@atmel.com> Message-ID: <200801050251.24277.vapier@gentoo.org> On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > +#define EM_AVR32???????0x18ad you guys arent in binutils yet eh ? you planning on keeping this value, or you going to be dropping down to a normal one ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/5fa0be2d/attachment.pgp From vapier at gentoo.org Fri Jan 4 23:54:10 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 02:54:10 -0500 Subject: [PATCH 4/7] add AVR32 optimized string functions In-Reply-To: <11943354101432-git-send-email-hcegtvedt@atmel.com> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354102079-git-send-email-hcegtvedt@atmel.com> <11943354101432-git-send-email-hcegtvedt@atmel.com> Message-ID: <200801050254.10862.vapier@gentoo.org> On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > +???????rjmp????__GI_memmove all of your .S files should be using HIDDEN_JUMPTARGET() rather than the __GI_ prefixes manually added. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/fae36e51/attachment.pgp From vapier at gentoo.org Fri Jan 4 23:56:09 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 02:56:09 -0500 Subject: [PATCH 5/7] add AVR32 pthread support In-Reply-To: <11943354101804-git-send-email-hcegtvedt@atmel.com> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354101432-git-send-email-hcegtvedt@atmel.com> <11943354101804-git-send-email-hcegtvedt@atmel.com> Message-ID: <200801050256.10182.vapier@gentoo.org> On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > +???????__asm__ __volatile__( > +???????????????"/* Inline test and set */\n" is it really a good idea to be sticking comments in the assembly output ? i guess as long as your assembler supports it as they wont be getting preprocessed by the the compiler ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/6a092a51/attachment.pgp From vapier at gentoo.org Fri Jan 4 23:57:49 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 02:57:49 -0500 Subject: [PATCH 6/7] add dynamic library support for AVR32 In-Reply-To: <1194335410549-git-send-email-hcegtvedt@atmel.com> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354101804-git-send-email-hcegtvedt@atmel.com> <1194335410549-git-send-email-hcegtvedt@atmel.com> Message-ID: <200801050257.49971.vapier@gentoo.org> On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > --- /dev/null > +++ b/ldso/ldso/avr32/elfinterp.c > @@ -0,0 +1,193 @@ > +/* > + * AVR32 ELF shared library loader suppport > + * > + * Copyright (C) 2004-2006 Atmel Corporation > + * > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > ........ what's with this spurious BSD license when all the rest of your code is LGPL like uClibc ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/c3474bb9/attachment.pgp From vapier at gentoo.org Fri Jan 4 23:59:56 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 02:59:56 -0500 Subject: asm/page.h: No such file or directory In-Reply-To: <20071105004533.393f51a4@siona> References: <1193853745.14833.8.camel@mercury.sprymusic> <2ccd6e3c0711030235x7002cfffn7c50e597d8e52cc5@mail.gmail.com> <20071105004533.393f51a4@siona> Message-ID: <200801050259.56579.vapier@gentoo.org> On Sunday 04 November 2007, Haavard Skinnemoen wrote: > On Sat, 3 Nov 2007 10:35:48 +0100 > > "Carmelo Amoroso" wrote: > > > arm-softfloat-linux-uclibc-strip -x -R .note -R .comment brk.o > > > ioperm.c:47:22: error: asm/page.h: No such file or directory > > > > It seems you don't have kernel headers properly configured > > for your architecture, or worst no properly installed. > > Check firstly if include/asm is a symlink to include/asm-. > > Actually, is about to be removed on all architectures, and > it's been empty for some time on several architectures (avr32, arm, ...) i made a preemptive strike in Gentoo a while ago and nuked page.h and friends so as to catch the bad packages earlier than most > I think ioperm.c should be fixed so that it doesn't rely on PAGE_SIZE > (which I assume is the reason why it needs asm/page.h in the first > place.) it was fixed some time ago ... but the version in Gentoo does not contain the fix, so from time to time, people get bitten -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/ceb980f5/attachment.pgp From vapier at gentoo.org Sat Jan 5 00:05:50 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 03:05:50 -0500 Subject: Need help to compile Apllication binaries In-Reply-To: <4731DCC0.7010608@st.com> References: <41483bfe0711070725l178e4b01ub3ca3dd1768be94@mail.gmail.com> <4731DCC0.7010608@st.com> Message-ID: <200801050305.51622.vapier@gentoo.org> On Wednesday 07 November 2007, Carmelo AMOROSO wrote: > harsh poshtiwala wrote: > > I have flashed uclibc baes kernel and root file system on ARM926 > > EJS based target. > > > > I didn't cross compile application binaries with uclibc_small > > cross compiler, but i had compiled it with arm-linux-gnueabi- > > glibc_small. this is probably the source of your problem ... your toolchains are all f-jucked. build a real toolchain targetting uClibc and it should work fine. > > When ever we try to execute the any APPLICATION binaries it gives > > error message file not found > > > > #pwd > > #tcuSw > > > > #./shu.out > > sh: /.shu.out: not found > > > > The same happens with all the application binaries. > > I suspect it is failing to load the dynamic linker (yes, the message is > not self-explaining !) unfortunately, there's no real way to pass that information up to the user. the kernel cannot find the interpreter in the ELF header so it returns "file not found" to the process attempting the exec. > Check you application with readelf and look for the interpreter entry. > It has to be > /lib/ld-uClibc.so.0; then check into your file system if it is there. readelf does not provide a way to get at that exactly ... looking at the program headers (-l) will usually provide it in a round-about way. or dump the .interp section with -x. those lucky people with pax-utils package on their system can use `scanelf -i` to explicitly get the interpreter :) -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/090c23a6/attachment-0001.pgp From vapier at gentoo.org Sat Jan 5 00:09:12 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 03:09:12 -0500 Subject: sys_errlist obsolete but replaced by what? In-Reply-To: <20071109010938.GB12648@cloud.net.au> References: <20071109010938.GB12648@cloud.net.au> Message-ID: <200801050309.12663.vapier@gentoo.org> On Thursday 08 November 2007, Hamish Moffatt wrote: > The help text for the sys_errlist feature says that it is deprecated and > may be removed in the future, but what is its replacement? i guess not everyone is fluent in this stuff so i added a note in the help text to refer them to strerror(3) as Ned said -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/3f9c3c39/attachment.pgp From carmelo73 at gmail.com Sat Jan 5 00:21:38 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sat, 05 Jan 2008 09:21:38 +0100 Subject: unresolved symbols with locale support In-Reply-To: <477EFB63.3010403@brooks.nu> References: <477E824D.6000700@brooks.nu> <477EFB63.3010403@brooks.nu> Message-ID: <477F3E12.9010805@gmail.com> Lane Brooks wrote: > I found my problem. It was stale binaries did not get installed correctly. > > Lane > Hi, please note that the current status of locale support is not fully completed. We at ST have a whole Linux distro build against uclibc with locale enabled comprising almost 500 packages (Xorg, glib2... see the whole list at ftp://ftp.stlinux.com/pub/stlinux/2.3/STLinux/sh4_uclibc). We are running some locale specific tests for 8bit locale and found some bugs into locale code we'll release hopefully to the community soon, but the support is generally working. Note that multi-byte locale support is only for UTF8 (we did not yet test it fully). uclibc doesn't provide gettext functions (if you need it, you can build the gettext libraries and link your apps against libintl a we actually did) Hope to be helpful. Cheers, Carmelo > Lane Brooks wrote: >> I recently turned on locale support in my uclibc build, and after >> recompiling everything, I am getting the following unresolved symbols >> when trying to run commands like python: >> >> python: symbol '__ctype_b': can't resolve symbol in lib 'python' >> >> I am new to locale support and am unsure how to hunt this problem down. >> >> I see that __ctype_b_loc is now defined. So is the problem with python >> or uclibc? >> >> Things were working fine for me before turning on locale support, but it >> seems I need locale support to compile xorg/gtk. >> >> Thanks, >> Lane Brooks >> _______________________________________________ >> uClibc mailing list >> uClibc at uclibc.org >> http://busybox.net/cgi-bin/mailman/listinfo/uclibc > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > From vapier at gentoo.org Sat Jan 5 00:17:21 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 03:17:21 -0500 Subject: Patch for Maverick Crunch support In-Reply-To: <1196207001.28768.29.camel@localhost.localdomain> References: <1196207001.28768.29.camel@localhost.localdomain> Message-ID: <200801050317.21965.vapier@gentoo.org> On Tuesday 27 November 2007, Brian Austin wrote: > This patch adds MAVERICK CRUNCH FPU support for the Cirrus Logic EP93XX > ARM9 Procs. i dont think it needs another special ifdef when it can be integrated into the existing arm mess ... ive done that in svn instead for future reference, please fix your mailer so it doesnt line wrap patches. or attach them so they dont get screwed. thanks! -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/7999bcee/attachment.pgp From vapier at gentoo.org Sat Jan 5 00:27:48 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 03:27:48 -0500 Subject: uClibc Support for gettext funtionality?? In-Reply-To: <4743E27B.9070004@st.com> References: <4743E27B.9070004@st.com> Message-ID: <200801050327.49201.vapier@gentoo.org> On Wednesday 21 November 2007, Carmelo AMOROSO wrote: > Vikas TM wrote: > > Hello all, > > > > Please help me to find answers for following questions > > > > 1. What version of uClibc supports gettext functionality? > > none > If you want to add this support into uCLibc will be appreciated. > Otherwise you may build gettext libraries against uClibc and then > explicitly link against libintl your applications requiring gettext > functions. > > > 2. Can I use mixture of both GLIBC and UCLIBC libraries in same > > environment? If so, should I need to do any special configuration > > setting? > > yes, search the list, there is a my post where I suggested how to use > --dynamic-linker option > for this purpose. And I remember some other suggested a link to to an > wrapper/tools > aimed to do this, likely better ... but I forgot the details. i'll reply here rather than the one you refer to (as that one is from mid-2006 and i doubt many people here have that in their mail still) there's no need to fiddle with dynamic linker if you have a properly configured toolchain. merely configure your uClibc's PREFIX (RUNTIME and DEVEL) to something like /fooie/uClibc and leave the ldso in /lib/ where the toolchain expects it. uClibc's ldso will do the rest. i wouldnt attempt to get glibc to go anywhere else other than the standard /lib/ as glibc isnt exactly configurable. in terms of filenames, the only one that would actually clash on the filesystem is libpthread.so.0 ... otherwise, you could have glibc and uclibc both living in /lib/ ... but unless you really know what you're doing, this is probably a bad idea :P -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/086f73a8/attachment.pgp From vapier at gentoo.org Sat Jan 5 00:58:24 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 03:58:24 -0500 Subject: termios2 support In-Reply-To: <475ECEF7.9070509@carallon.com> References: <475ECEF7.9070509@carallon.com> Message-ID: <200801050358.25037.vapier@gentoo.org> On Tuesday 11 December 2007, Will Wagner wrote: > I would like support for arbitrary baud rates with serial ports with > through uclibc. > > I have looked at the uclibc code and there appear to be some support for > this in kernel_termios.h but it is limited to alpha & powerpc. It also > does not seem to use the kernel ioctl's TCGETS2 & TCSETS2 that are > available with 2.6 not really. the fact that the speed members exist in the termios struct for some ports is irrelevant so long as the TCGET/TCSET ioctl's are being used. for all the termios having different structures/layouts, the kernel implements the tty layer the same for everyone. it's just the structure itself which has these stupid arch/ABI warts because it's exposed to userspace. > Can anyone suggest the best way to extend x86 so that it has support for > c_ispeed & c_ospeed in the termios structure? I believe that with the > 2.6 kernel all architectures ktermios struct contains c_ispeed & > c_ospeed and so it could be added generically. Is that correct? Looks > like TCGETS2 & TCSETS2 are supported on both x86 and arm, is that right? you dont need libc support to access the functionality now ... you can cheat by doing: #include #include ... struct termios2 t; ioctl(fd, TCGETS2, &t); t.c_ospeed = t.c_ispeed = 543210; t.c_cflag &= ~CBAUD; t.c_cflag |= BOTHER; ioctl(fd, TCSETS2, &t); ... i hesitate to add support for termios2 to uClibc in case the glibc guys implement things in a different way. the last thing i want is that sort of ugly API incompatibility. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/098d957b/attachment.pgp From vapier at gentoo.org Sat Jan 5 01:11:02 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 04:11:02 -0500 Subject: error when building gcc using buildroot/toolchain In-Reply-To: References: Message-ID: <200801050411.03298.vapier@gentoo.org> On Sunday 16 December 2007, Joshua Lenmarc wrote: > Sample problem here: > > Ubuntu 7.04 > > /home/xxx/Desktop/buildroot/toolchain_build_mips/gcc-4.2.1/gcc/crtstuff.c:1 >: error: unsupported combination: -mabicalls -mabi=eabi perhaps you should try mailing the buildroot list since this is not a uClibc problem in any way -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/05537bca/attachment.pgp From vapier at gentoo.org Sat Jan 5 01:14:59 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 04:14:59 -0500 Subject: readelf/ldconfig confused about ELF header In-Reply-To: <20071031061005.GA16307@cloud.net.au> References: <20071031061005.GA16307@cloud.net.au> Message-ID: <200801050414.59973.vapier@gentoo.org> On Wednesday 31 October 2007, Hamish Moffatt wrote: > I'm using buildroot to compile for armeb on a x86-64 (little-endian) host. please use the buildroot mailing list in the future > uclibc's readelf and ldconfig are giving confusing results reading the > headers of compiled libraries. > > Programs run ok, but ldconfig decides that my target has mixed > byte-order libraries and generates a wrong-endianness ld.so.conf. > > readelf says the right things for uClibc's own libraries: > > [ 5:00PM] hamish at bach:europaboot/root/lib $ > ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-uclibcgnu-readelf you are running readelf from binutils, so that isnt really uClibc's concern ... dunno about the ldconfig thing you mention though -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/91d5c4f2/attachment.pgp From vapier at gentoo.org Sat Jan 5 01:21:44 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 04:21:44 -0500 Subject: Testing of memcmp(). Possible patch to tester.c In-Reply-To: <1193510487.26395.29.camel@localhost> References: <1193510487.26395.29.camel@localhost> Message-ID: <200801050421.45335.vapier@gentoo.org> On Saturday 27 October 2007, Mats Erik Andersson wrote: > the attached difference file addresses the problem of > better detecting a malfunctioning memcmp() call. It concerns > the file > > uClibc-0.9.29/test/string/tester.c we blatantly steal this test from glibc ... any enhancements ive made i pushed back upstream as appropriate. > in the test suite. Where possible the old test cases were > rebuilt to avoid the return values (from memcmp) +1 and -1, > but still only positivity and negativity are tested for. > This was done in order to better disclose problems with > the optimized and architecture specific implementations. > In addition, there are some new test cases gleaned from > Dropbear, and which conduct tests with shifting alignment. > Of course, not all of these twenty test cases are independent, > but in more verbose forms they were instrumental when I > debugged architecture specific assembly code for an embedded > system (not yet incorporated into the code base of uClibc). going by your description, it sounds like this would be something the glibc guys would accept. can you please resend this entire e-mail to libc-alpha at sourceware.org ? i'll take care of merging it into uClibc's copy. > It was also essential to use a flag "-fno-builtin" to detect the > failures, both for the old test cases and these new ones. which should already be happening ... the string Makefile makes sure to add this flag > Based I on this recent experience, I have begun developing > a modified testing machinery that better would issue warnings > for false positives. The effort to avoid return values +1 and -1 > is an afterglow of this methodology. Since the present test > suite is somewhat awkward to use in cross compiled settings, > I might come back to that issue another time. the test framework should be converted to dejagnu ... ive spent a little time on this, but much more is needed -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/6861ef77/attachment.pgp From vapier at gentoo.org Sat Jan 5 01:24:54 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 04:24:54 -0500 Subject: [patch] clean up some whitespaces In-Reply-To: <1193397040.27730.97.camel@localhost.localdomain> References: <1193397040.27730.97.camel@localhost.localdomain> Message-ID: <200801050424.54849.vapier@gentoo.org> On Friday 26 October 2007, Hans-Christian Egtvedt wrote: > See attached patch. merged, cheers -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/d679b5cb/attachment-0001.pgp From vapier at gentoo.org Sat Jan 5 01:29:16 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 04:29:16 -0500 Subject: [PATCH] libc: cleanup some compile warnings In-Reply-To: <11933880373405-git-send-email-hcegtvedt@atmel.com> References: <11933880373405-git-send-email-hcegtvedt@atmel.com> Message-ID: <200801050429.17099.vapier@gentoo.org> On Friday 26 October 2007, Hans-Christian Egtvedt wrote: > Signed-off-by: Hans-Christian Egtvedt > --- > libc/inet/rpc/create_xid.c | 2 +- > libc/inet/rpc/xdr.c | 12 ++++++------ > libc/inet/rpc/xdr_intXX_t.c | 4 ++-- the rpc code is horrendous ... i'm of the opinion we should encourage people to use the TIRPC library rather than the SUNRPC code in uClibc. the SUNRPC has known limitations (which are addressed by the TIRPC library), any drepper has already denied enhancements to SUNRPC in glibc (he regrets ever having merged it actually). i'm guessing these casts are for strict aliased warnings ? i dont think casting them away fixes the problem. > libc/stdio/_scanf.c | 8 ++++---- > libc/stdio/_vfprintf.c | 8 ++++---- > libc/stdio/vsnprintf.c | 4 ++-- merged, cheers -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/7ea52104/attachment.pgp From vapier at gentoo.org Sat Jan 5 01:31:09 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 04:31:09 -0500 Subject: Any documentation about how uClibc would like new architecture patches? In-Reply-To: <1193292433.27730.50.camel@localhost.localdomain> References: <1193292433.27730.50.camel@localhost.localdomain> Message-ID: <200801050431.10553.vapier@gentoo.org> On Thursday 25 October 2007, Hans-Christian Egtvedt wrote: > I am in the work of submitting the AVR32 architecture fork of uClibc, > and would like to know if you have a preferd way of receiving the > patches? > > My plan is to pull down the latest snapshot, do a merge in my local > repository (for the record I use git), test and verify that it works as > intended and then submit patches. > > I was planning on splitting the patches into ldso.patch, libc.patch and > libpthread.patch. Or is a huge patch ok? > > The total size of the diff is 99316 bytes, 3582 lines. it's already been done, but all patches should be posted to the list. i guess a more "developer guide" page on the website is in order ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/14994f1a/attachment.pgp From vapier at gentoo.org Sat Jan 5 02:03:45 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 05:03:45 -0500 Subject: Xtensa support for uClibc [1/9] In-Reply-To: <20071206204937.99A523074E@atlanta.zankel.net> References: <20071206204937.99A523074E@atlanta.zankel.net> Message-ID: <200801050503.46598.vapier@gentoo.org> On Thursday 06 December 2007, Chris Zankel wrote: > The following patches add support for the Xtensa processor architecture > to uClibc. They are based on a recent SVN checkout (12/05/2007). dont really see anything that sticks out as "hey i suck!" ;) it seems patch [5/9] was duplicated, so i skipped the first posting you should update utils/ldd.c accordingly > I welcome any feedback and would appreciate it if you could include the > patches into the mainline tree. I am certainly committed to maintain the > port. ive merged your patchset. if you would like an account to maintain your port, please e-mail me your desired username as well as your pub ssh key. then you can update the top level MAINTAINERS file to include your info -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/82c2f595/attachment.pgp From vapier at gentoo.org Sat Jan 5 02:09:29 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 05:09:29 -0500 Subject: complier error In-Reply-To: <97ed97ef0711062328g116815d0gbbbd1697bc251f7a@mail.gmail.com> References: <97ed97ef0711062328g116815d0gbbbd1697bc251f7a@mail.gmail.com> Message-ID: <200801050509.29630.vapier@gentoo.org> On Wednesday 07 November 2007, Liu Hua wrote: > when I compile uClibc for arm926ejt , it shows errors below: > AS libc/sysdeps/linux/arm/sigrestorer.os > libc/sysdeps/linux/arm/sigrestorer.S: Assembler messages: > libc/sysdeps/linux/arm/sigrestorer.S: 43: Error: invalid constant -- > 'mov r7, $((0x900000+119))' > libc/sysdeps/linux/arm/sigrestorer.S: 65: Error: invalid constant -- > 'mov r7, $((0x900000+173))' > make[1]: *** [libc/sysdeps/linux/arm/sigrestorer.os] Error 1 > make: *** [lib/libc.so.0] Error 2 you'll need to provide information about your actual setup. simply posting an error message usually isnt helpful. what version of uClibc ? what version of gcc ? what version of kernel headers ? what is your arm target (eabi/thumb/etc...) ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/ea241c4f/attachment.pgp From hamish at cloud.net.au Sat Jan 5 05:38:32 2008 From: hamish at cloud.net.au (Hamish Moffatt) Date: Sun, 6 Jan 2008 00:38:32 +1100 Subject: readelf/ldconfig confused about ELF header In-Reply-To: <200801050414.59973.vapier@gentoo.org> References: <20071031061005.GA16307@cloud.net.au> <200801050414.59973.vapier@gentoo.org> Message-ID: <20080105133832.GA17694@cloud.net.au> On Sat, Jan 05, 2008 at 04:14:59AM -0500, Mike Frysinger wrote: > On Wednesday 31 October 2007, Hamish Moffatt wrote: > > I'm using buildroot to compile for armeb on a x86-64 (little-endian) host. > > please use the buildroot mailing list in the future I thought it was an ldconfig bug, but it turned out to be a problem with one of the other packages in my buildroot configuration. Patch submitted and applied to the buildroot repository already. thanks Hamish -- Hamish Moffatt VK3SB From Brian.Austin at cirrus.com Sat Jan 5 06:31:03 2008 From: Brian.Austin at cirrus.com (Austin, Brian) Date: Sat, 5 Jan 2008 08:31:03 -0600 Subject: Patch for Maverick Crunch support References: <1196207001.28768.29.camel@localhost.localdomain> <200801050317.21965.vapier@gentoo.org> Message-ID: So this support will be in the next release? Thanks, I sent an email asking about submissions and how best to send them, but never recieved a reply, so I just diff'd to pine and sent. sorry bout the wrapping. I'll just attach on emails from now on. thanks again, Brian ________________________________ From: Mike Frysinger [mailto:vapier at gentoo.org] Sent: Sat 1/5/2008 2:17 AM To: uclibc at uclibc.org Cc: Austin, Brian Subject: Re: Patch for Maverick Crunch support On Tuesday 27 November 2007, Brian Austin wrote: > This patch adds MAVERICK CRUNCH FPU support for the Cirrus Logic EP93XX > ARM9 Procs. i dont think it needs another special ifdef when it can be integrated into the existing arm mess ... ive done that in svn instead for future reference, please fix your mailer so it doesnt line wrap patches. or attach them so they dont get screwed. thanks! -mike From Brian.Austin at cirrus.com Sat Jan 5 06:48:32 2008 From: Brian.Austin at cirrus.com (Austin, Brian) Date: Sat, 5 Jan 2008 08:48:32 -0600 Subject: Patch for Maverick Crunch support References: <1196207001.28768.29.camel@localhost.localdomain> <200801050317.21965.vapier@gentoo.org> Message-ID: ah, found it. looks good. Thanks. ________________________________ From: Mike Frysinger [mailto:vapier at gentoo.org] Sent: Sat 1/5/2008 2:17 AM To: uclibc at uclibc.org Cc: Austin, Brian Subject: Re: Patch for Maverick Crunch support On Tuesday 27 November 2007, Brian Austin wrote: > This patch adds MAVERICK CRUNCH FPU support for the Cirrus Logic EP93XX > ARM9 Procs. i dont think it needs another special ifdef when it can be integrated into the existing arm mess ... ive done that in svn instead for future reference, please fix your mailer so it doesnt line wrap patches. or attach them so they dont get screwed. thanks! -mike From alec at sensi.org Sat Jan 5 07:27:16 2008 From: alec at sensi.org (Alexander Voropay) Date: Sat, 5 Jan 2008 18:27:16 +0300 Subject: mipsel memcpy & gcc3.4.6 Message-ID: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> Hi! Can anyone help with this issue ? I've opened a bug in the busybox tracking system: http://busybox.net/bugs/view.php?id=1894 It there any way to compile uClibc for mipsel with gcc 3.4.6 ? Some notes: - uClibc uses platform-specific memcpy (libc/string/mips/memcpy.os) Is it possible to swith to the "generic" memcpy version ? - The bug in the AS (preprocessor), not in the GCC itself -- -=AV=- From vapier at gentoo.org Sat Jan 5 08:25:08 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 11:25:08 -0500 Subject: mipsel memcpy & gcc3.4.6 In-Reply-To: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> References: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> Message-ID: <200801051125.09281.vapier@gentoo.org> On Saturday 05 January 2008, Alexander Voropay wrote: > Can anyone help with this issue ? > > I've opened a bug in the busybox tracking system: > > http://busybox.net/bugs/view.php?id=1894 i already told you it wasnt a bug in uClibc ... > It there any way to compile uClibc for mipsel with gcc 3.4.6 ? remove the -std=gnu99 flag when building memcpy.S if you like > - uClibc uses platform-specific memcpy (libc/string/mips/memcpy.os) > Is it possible to swith to the "generic" memcpy version ? that's a configuration choice on your side ... review your uClibc configuration file > - The bug in the AS (preprocessor), not in the GCC itself incorrect ... the bug is in the gcc preprocessor. it errors out before it even gets a chance to output assembly which gas would then process. notice how the error message is prefixed with gcc there and not gas. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/39f0007b/attachment.pgp From vapier at gentoo.org Sat Jan 5 08:29:09 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 11:29:09 -0500 Subject: Patch for Maverick Crunch support In-Reply-To: References: <1196207001.28768.29.camel@localhost.localdomain> <200801050317.21965.vapier@gentoo.org> Message-ID: <200801051129.09808.vapier@gentoo.org> On Saturday 05 January 2008, Austin, Brian wrote: > I sent an email asking about submissions and how best to send them, but > never recieved a reply, so I just diff'd to pine and sent. sorry bout the > wrapping. i just searched my uClibc folder and didnt find any e-mails from you ... oh well, i'll add this to the "developer" page on the uclibc.org website > I'll just attach on emails from now on. try to make sure they are set to "auto-display" or however :) -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/703161fa/attachment-0001.pgp From vapier at gentoo.org Sat Jan 5 11:09:29 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 14:09:29 -0500 Subject: developer documentation Message-ID: <200801051409.29760.vapier@gentoo.org> i've created a general guide for contributing/developing: http://uclibc.org/developing.html if people could give it a quick look over, that'd be great -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/048321e9/attachment.pgp From Brian.Austin at cirrus.com Sat Jan 5 11:40:53 2008 From: Brian.Austin at cirrus.com (Austin, Brian) Date: Sat, 5 Jan 2008 13:40:53 -0600 Subject: developer documentation References: <200801051409.29760.vapier@gentoo.org> Message-ID: Looks good. This will help alot. thanks for posting this. Regards, Brian ________________________________ From: uclibc-bounces at uclibc.org on behalf of Mike Frysinger Sent: Sat 1/5/2008 1:09 PM To: uclibc at uclibc.org Subject: developer documentation i've created a general guide for contributing/developing: http://uclibc.org/developing.html if people could give it a quick look over, that'd be great -mike From vapier at gentoo.org Sat Jan 5 16:02:45 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 19:02:45 -0500 Subject: [PATCH] uclibc extern inline In-Reply-To: <4759E2F6.3010309@mvista.com> References: <4759E2F6.3010309@mvista.com> Message-ID: <200801051902.46434.vapier@gentoo.org> On Friday 07 December 2007, Khem Raj wrote: > Compiling with gcc 4.3 I get a lot of warning about inlining. > with -std=c99 or -std=gnu99 GCC implements ISO C99 inline semantics > unless -fgnu89-inline is used. the warnings are in gcc 4.2 as well. ive imported the extern inline defines from glibc into our cdefs.h and converted all of the pthreads code to use it. i think that covers everything without forcing -fgnu89-inline ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/6259db67/attachment.pgp From vapier at gentoo.org Sat Jan 5 16:10:28 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 5 Jan 2008 19:10:28 -0500 Subject: [PATCH] Fix dladdr return value when cannot find symbol In-Reply-To: <47603EC4.6080609@st.com> References: <12b5f1ef0711292147x5e74be2dn41bcb8b9c3d567ba@mail.gmail.com> <475D57A0.1050507@st.com> <47603EC4.6080609@st.com> Message-ID: <200801051910.29409.vapier@gentoo.org> On Wednesday 12 December 2007, Carmelo AMOROSO wrote: > while running more tests on this (indeed never used dladdr in the past), which tests ? our dl tests certainly dont have the coverage anywhere close to what i wish they did ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080105/698fd9df/attachment.pgp From vapier at gentoo.org Sat Jan 5 22:19:40 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 01:19:40 -0500 Subject: Alignment fixups for gethostbyname_r In-Reply-To: <476CB01E.2010402@gmail.com> References: <20071219165728.GA3828@caradoc.them.org> <476CB01E.2010402@gmail.com> Message-ID: <200801060119.40786.vapier@gentoo.org> On Saturday 22 December 2007, Carmelo Amoroso wrote: > Daniel Jacobowitz wrote: > > MontaVista noticed that when their kernels were configured to trap > > on unaligned access gethostbyname_r could mysteriously crash. I > > tracked this down to an unaligned buffer being passed to > > gethostbyname_r from some other part of uClibc (afraid I don't > > remember where from any more). We have to pad the beginning of > > the buffer to a pointer alignment before we store pointers in > > it. > > I've merged it into my sh4-nptl branch to do some tests, > but not possible until Jan 3rd. > The patch is surely ok, but, the caller of the gethostbyname is the > real cause of the error, that could happen in some other part, > being the passed buffer unaligned. i dont think so. the gethostbyname_r() API takes a char* for its scratch space which means no alignment requirements are stipulated. internally, gethostbyname_r() needs to make sure things are aligned properly for however it uses the scratch space. the nice thing about alignment tests are they're easy to write ... the bad thing is that not everyone has native alignment requirements, so it'll pass fine on the common systems (x86/x86_64), warn on the semi-common (arm/hppa) (and no one will notice), and only fail on the uncommon (Blackfin). -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/d2615860/attachment.pgp From vapier at gentoo.org Sat Jan 5 22:35:53 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 01:35:53 -0500 Subject: Alignment fixups for gethostbyname_r In-Reply-To: <20071219165728.GA3828@caradoc.them.org> References: <20071219165728.GA3828@caradoc.them.org> Message-ID: <200801060135.53689.vapier@gentoo.org> On Wednesday 19 December 2007, Daniel Jacobowitz wrote: > --- libc/inet/resolv.c??(revision 189757) > +++ libc/inet/resolv.c??(local) > @@ -1534,6 +1534,15 @@ int attribute_hidden __read_etc_hosts_r( > ????????char *cp, **alias; > ????????int aliases, i, ret = HOST_NOT_FOUND; > ? > +???????/* Align to at least the size of a char * so we can put > +??????? ? pointers in it. ?*/ > +???????i = (unsigned long) buf % sizeof(char *); > +???????i = (sizeof(char *) - i) % sizeof(char *); > +???????if (buflen < i) > +???????????????return ERANGE; > +???????buf+=i; > +???????buflen-=i; > + considering buflen gets checked constantly before being utilized, i dont think we need an additional check to see if it could possibly store a pointer. we just need to make sure the adjustment alone doesnt cause size_t underflow. i think this should be sufficient: /* Make sure the incoming char * buffer is aligned enough to * handle our random structures. This define is the same as we * use for malloc alignment (which has same requirements). */ i = (size_t)buf & __alignof__(double __attribute_aligned__ (sizeof(size_t))); if (buflen < i) return ERANGE; buf += i; buflen += i; -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/fa500974/attachment.pgp From vapier at gentoo.org Sat Jan 5 22:44:24 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 01:44:24 -0500 Subject: [PATCH] c99 math func log2 In-Reply-To: <20071107230551.GF6510@aon.at> References: <1193836475.26459.34.camel@nc.nor.wtbts.org> <1194476516.18195.41.camel@nc.nor.wtbts.org> <20071107230551.GF6510@aon.at> Message-ID: <200801060144.25564.vapier@gentoo.org> On Wednesday 07 November 2007, Bernhard Fischer wrote: > If we can subsummize some or individual funcs depending one a certain > standard, then all is well (see bsd-compat in e.g. network or others). > If they are non-standard but just serve as glibc-compat, then please > state so both in configury as in help-text and resubmit accordingly. for math functions, the groupings currently are: - all functions required by C99 - POSIX/IEEE 1003.1b-1993 functions i imagine we should add standard options: - float wrappers (what we have now -- all float funcs just call double funcs) - float versions (actually import the float variations) the only other piece would be a way to provide a custom list of desired math functions ... shouldnt be terribly hard for libm actually seeing as how most files are 1 func per file ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/89bcae91/attachment.pgp From vapier at gentoo.org Sat Jan 5 22:45:12 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 01:45:12 -0500 Subject: [PATCH] c99 math func log2 In-Reply-To: <1193836475.26459.34.camel@nc.nor.wtbts.org> References: <1193836475.26459.34.camel@nc.nor.wtbts.org> Message-ID: <200801060145.12983.vapier@gentoo.org> On Wednesday 31 October 2007, Natanael Copa wrote: > Here is a patch for the c99 math func log2(). If this gets applied I > will look into the other c99 math funcs as well. is this function actually needed by something ? the current working policy has been to merge C99 functions really only on demand ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/fb29882b/attachment.pgp From vapier at gentoo.org Sat Jan 5 22:49:19 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 01:49:19 -0500 Subject: building a new (nios2) toolchain starting with uclibc In-Reply-To: References: Message-ID: <200801060149.20589.vapier@gentoo.org> On Thursday 18 October 2007, Robert P. J. Day wrote: > as an experiment, i want to create an updated version of a Nios II > toolchain, and i thought i'd start with testing whether i could just > compile the latest version of uclibc with the older toolchain, and > take it from there. > > first, i already have a nios2 cross-compiler toolchain from here: > > http://nioswiki.jot.com/WikiHome/OperatingSystems/%C2%B5Clinux/BinaryToolch >ain > > that toolchain is based on gcc-3.4.6 so, as a first exercise, i > thought it would be educational to see if i could cross-compile the > latest svn checkout of uclibc with it. there should be no problems with gcc-3.4.6 and any architecture on the uClibc side of things. there is someone on bugs.uclibc.org who has spent a lot of time getting nios2 things working in uClibc again. > -rw-r--r-- 1 rpjday rpjday 5544 2006-05-07 09:57 elf2flt.ld ah elf2flt, how i stab thee ... this will require custom modifications to your binutils install step > is this a sane way to start the process -- just to see where the > older toolchain has problems building the current version of uclibc, > and seeing if there's an obvious fix? thanks. i'm pretty sure svn trunk of uClibc actually has a decent nios2 status. it'd prob be faster to go the other way -- enable everything you expect and only turn off upon failure. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/e6436d64/attachment.pgp From vapier at gentoo.org Sat Jan 5 22:52:00 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 01:52:00 -0500 Subject: Alignment fixups for gethostbyname_r In-Reply-To: <200801060135.53689.vapier@gentoo.org> References: <20071219165728.GA3828@caradoc.them.org> <200801060135.53689.vapier@gentoo.org> Message-ID: <200801060152.00905.vapier@gentoo.org> On Sunday 06 January 2008, Mike Frysinger wrote: > buflen += i; err, that should be -= of course ... but you get the gist of where i'm trying to take the changes ;) -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/ff49bfa3/attachment.pgp From vapier at gentoo.org Sat Jan 5 23:54:31 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 02:54:31 -0500 Subject: need for getifaddrs in uclibc In-Reply-To: <1194461704.18195.35.camel@nc.nor.wtbts.org> References: <1194453923.18195.12.camel@nc.nor.wtbts.org> <4732064F.2080200@arcor.de> <1194461704.18195.35.camel@nc.nor.wtbts.org> Message-ID: <200801060254.32488.vapier@gentoo.org> On Wednesday 07 November 2007, Natanael Copa wrote: > On Wed, 2007-11-07 at 19:39 +0100, Jason Curl wrote: > > Natanael Copa wrote: > > > Hi, > > > > > > Does anyone know a susv3/POSIX compliant way to list all ipv6 > > > interfaces? I bet there are no. ioctl(SIOCGIFCONF) ignores ipv6 > > > interfaces, I just tested. > > > > What does ifconfig do in BusyBox? Does that do what you want? > > talks directly to netlink, with is even more non portable. i believe that's about the only way to get all the info you need anymore in Linux ... > > When I implemented something across multiple platforms only for IPv4 > > that was a real nightmare (Solaris, Linux, uClibc, FreeBSD, Cygwin). > > > > > I suggest implementing a getifaddrs in uclibc, even if its not > > > susv3/POSIX. > > I checked around. if_nameindex will list all your network interfaces, > which gets me half the way. but I still havent found out how to get a > list of ipv6 addresses from a given device name. from my testing, if_nameindex wont even enumerate all possible interfaces via the ioctl() interface. you need to go through netlink to get it all. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/0b98ebb1/attachment-0001.pgp From vapier at gentoo.org Sat Jan 5 23:56:25 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 02:56:25 -0500 Subject: need for getifaddrs in uclibc In-Reply-To: <47335657.7060606@arcor.de> References: <1194453923.18195.12.camel@nc.nor.wtbts.org> <1194461704.18195.35.camel@nc.nor.wtbts.org> <47335657.7060606@arcor.de> Message-ID: <200801060256.26111.vapier@gentoo.org> On Thursday 08 November 2007, Jason Curl wrote: > Then "sysctl()" is supposed to be the successor of "ioctl()". UNP talks > about using the routing sockets to get the information for each > interface (sounds similar to netlink, but different enough). from what i've seen on lkml, they're trying pretty hard to kill sysctl() since it just doesnt scale the way they need to -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/458a170d/attachment.pgp From vapier at gentoo.org Sat Jan 5 23:59:15 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 02:59:15 -0500 Subject: need for getifaddrs in uclibc In-Reply-To: <20071110064430.GA25837@mvista.com> References: <1194453923.18195.12.camel@nc.nor.wtbts.org> <20071110064430.GA25837@mvista.com> Message-ID: <200801060259.16001.vapier@gentoo.org> On Saturday 10 November 2007, Khem Raj wrote: > On Wed, Nov 07, 2007 at 05:45:23PM +0100, Natanael Copa wrote: > > Hi, > > > > Does anyone know a susv3/POSIX compliant way to list all ipv6 > > interfaces? I bet there are no. ioctl(SIOCGIFCONF) ignores ipv6 > > interfaces, I just tested. > > > > I suggest implementing a getifaddrs in uclibc, even if its not > > susv3/POSIX. > > here is one implementation based on glibc getifaddrs(). It should get > compiled in when you have UCLIBC_USE_NETLINK enabled. the netlink detection/assumption stuff should probably be scrubbed in favor of the have netflink define. > Let me know if this is OK? Natanael: get a chance to test this ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/e0850a63/attachment.pgp From carmelo73 at gmail.com Sun Jan 6 00:51:10 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sun, 06 Jan 2008 09:51:10 +0100 Subject: [PATCH] Fix dladdr return value when cannot find symbol In-Reply-To: <200801051910.29409.vapier@gentoo.org> References: <12b5f1ef0711292147x5e74be2dn41bcb8b9c3d567ba@mail.gmail.com> <475D57A0.1050507@st.com> <47603EC4.6080609@st.com> <200801051910.29409.vapier@gentoo.org> Message-ID: <4780967E.1060609@gmail.com> Mike Frysinger wrote: > On Wednesday 12 December 2007, Carmelo AMOROSO wrote: >> while running more tests on this (indeed never used dladdr in the past), > > which tests ? our dl tests certainly dont have the coverage anywhere close to > what i wish they did ... > -mike > Hi Mike, some tests written from scratch, nothing special, just to call and check dladdr results. Due to long vacation we are a bit late in completing the patch. Hopefully my collegue will finish by the end of next week. Anyway, what about my previous patch ? Carmelo > > ------------------------------------------------------------------------ > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From carmelo73 at gmail.com Sun Jan 6 00:53:11 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sun, 06 Jan 2008 09:53:11 +0100 Subject: Alignment fixups for gethostbyname_r In-Reply-To: <200801060119.40786.vapier@gentoo.org> References: <20071219165728.GA3828@caradoc.them.org> <476CB01E.2010402@gmail.com> <200801060119.40786.vapier@gentoo.org> Message-ID: <478096F7.4010800@gmail.com> Mike Frysinger wrote: > On Saturday 22 December 2007, Carmelo Amoroso wrote: >> Daniel Jacobowitz wrote: >>> MontaVista noticed that when their kernels were configured to trap >>> on unaligned access gethostbyname_r could mysteriously crash. I >>> tracked this down to an unaligned buffer being passed to >>> gethostbyname_r from some other part of uClibc (afraid I don't >>> remember where from any more). We have to pad the beginning of >>> the buffer to a pointer alignment before we store pointers in >>> it. >> I've merged it into my sh4-nptl branch to do some tests, >> but not possible until Jan 3rd. >> The patch is surely ok, but, the caller of the gethostbyname is the >> real cause of the error, that could happen in some other part, >> being the passed buffer unaligned. > > i dont think so. the gethostbyname_r() API takes a char* for its scratch > space which means no alignment requirements are stipulated. Right, I was completely wrong ;-) Carmelo From michael at talamasca.ocis.net Sun Jan 6 01:35:11 2008 From: michael at talamasca.ocis.net (Michael Deutschmann) Date: Sun, 6 Jan 2008 01:35:11 -0800 (PST) Subject: Alignment fixups for gethostbyname_r In-Reply-To: <200801060119.40786.vapier@gentoo.org> Message-ID: <%D6JgHNIPK@khar-pern.talamasca.ocis.net> Mike Frysinger wrote: > the nice thing about alignment tests are they're easy to write ... the bad > thing is that not everyone has native alignment requirements, so it'll pass > fine on the common systems (x86/x86_64), warn on the semi-common (arm/hppa) > (and no one will notice), and only fail on the uncommon (Blackfin). Actually, there's an obscure flag bit that puts an IA-32 processor in a mode where it is fascist about alignment. So it should be possible to derive a special uClibc build which operates with the flag set, and will fault if there are alignment issues. ---- Michael Deutschmann From rep.dot.nop at gmail.com Sun Jan 6 05:30:33 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sun, 6 Jan 2008 14:30:33 +0100 Subject: Alignment fixups for gethostbyname_r In-Reply-To: <%D6JgHNIPK@khar-pern.talamasca.ocis.net> References: <200801060119.40786.vapier@gentoo.org> <%D6JgHNIPK@khar-pern.talamasca.ocis.net> Message-ID: <20080106133033.GT17973@aon.at> On Sun, Jan 06, 2008 at 01:35:11AM -0800, Michael Deutschmann wrote: >Mike Frysinger wrote: >> the nice thing about alignment tests are they're easy to write ... the bad >> thing is that not everyone has native alignment requirements, so it'll pass >> fine on the common systems (x86/x86_64), warn on the semi-common (arm/hppa) >> (and no one will notice), and only fail on the uncommon (Blackfin). > >Actually, there's an obscure flag bit that puts an IA-32 processor in a mode >where it is fascist about alignment. What would that be? Please give a useable example including a config option that can be used for debugging purposes only. TIA, > So it should be possible to derive a >special uClibc build which operates with the flag set, and will fault if >there are alignment issues. From rep.dot.nop at gmail.com Sun Jan 6 05:53:45 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sun, 6 Jan 2008 14:53:45 +0100 Subject: [PATCH] uclibc extern inline In-Reply-To: <200801051902.46434.vapier@gentoo.org> References: <4759E2F6.3010309@mvista.com> <200801051902.46434.vapier@gentoo.org> Message-ID: <20080106135345.GU17973@aon.at> On Sat, Jan 05, 2008 at 07:02:45PM -0500, Mike Frysinger wrote: >On Friday 07 December 2007, Khem Raj wrote: >> Compiling with gcc 4.3 I get a lot of warning about inlining. >> with -std=c99 or -std=gnu99 GCC implements ISO C99 inline semantics >> unless -fgnu89-inline is used. > >the warnings are in gcc 4.2 as well. ive imported the extern inline defines >from glibc into our cdefs.h and converted all of the pthreads code to use it. >i think that covers everything without forcing -fgnu89-inline ? I'd prefer not to rely on gnu89-inline (and not on gnu99 too, fwiw). Trunk should now start to behave without gnu89-inline. From vapier at gentoo.org Sun Jan 6 10:16:45 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 13:16:45 -0500 Subject: [PATCH] uclibc extern inline In-Reply-To: <20080106135345.GU17973@aon.at> References: <4759E2F6.3010309@mvista.com> <200801051902.46434.vapier@gentoo.org> <20080106135345.GU17973@aon.at> Message-ID: <200801061316.46510.vapier@gentoo.org> On Sunday 06 January 2008, Bernhard Fischer wrote: > On Sat, Jan 05, 2008 at 07:02:45PM -0500, Mike Frysinger wrote: > >On Friday 07 December 2007, Khem Raj wrote: > >> Compiling with gcc 4.3 I get a lot of warning about inlining. > >> with -std=c99 or -std=gnu99 GCC implements ISO C99 inline semantics > >> unless -fgnu89-inline is used. > > > >the warnings are in gcc 4.2 as well. ive imported the extern inline > > defines from glibc into our cdefs.h and converted all of the pthreads > > code to use it. i think that covers everything without forcing > > -fgnu89-inline ? > > I'd prefer not to rely on gnu89-inline (and not on gnu99 too, fwiw). > Trunk should now start to behave without gnu89-inline. that's what i was asking ... i think what i committed precludes us needing to pick one way or the other via a compiler flag for the branch, i just forced the compiler flag, as that's a sane fix for there -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080106/7b60d225/attachment.pgp From natanael.copa at gmail.com Mon Jan 7 01:31:39 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Mon, 07 Jan 2008 10:31:39 +0100 Subject: [PATCH] c99 math func log2 In-Reply-To: <200801060145.12983.vapier@gentoo.org> References: <1193836475.26459.34.camel@nc.nor.wtbts.org> <200801060145.12983.vapier@gentoo.org> Message-ID: <1199698299.8770.28.camel@nc.nor.wtbts.org> On Sun, 2008-01-06 at 01:45 -0500, Mike Frysinger wrote: > On Wednesday 31 October 2007, Natanael Copa wrote: > > Here is a patch for the c99 math func log2(). If this gets applied I > > will look into the other c99 math funcs as well. > > is this function actually needed by something ? the current working policy > has been to merge C99 functions really only on demand ... > -mike No, its not needed by anything afaik. I dropped adding math funcs since it seems like the missing are (almost) never used. -nc From drow at false.org Mon Jan 7 05:22:29 2008 From: drow at false.org (Daniel Jacobowitz) Date: Mon, 7 Jan 2008 08:22:29 -0500 Subject: Alignment fixups for gethostbyname_r In-Reply-To: <200801060135.53689.vapier@gentoo.org> References: <20071219165728.GA3828@caradoc.them.org> <200801060135.53689.vapier@gentoo.org> Message-ID: <20080107132229.GA31895@caradoc.them.org> On Sun, Jan 06, 2008 at 01:35:53AM -0500, Mike Frysinger wrote: > On Wednesday 19 December 2007, Daniel Jacobowitz wrote: > > --- libc/inet/resolv.c??(revision 189757) > > +++ libc/inet/resolv.c??(local) > > @@ -1534,6 +1534,15 @@ int attribute_hidden __read_etc_hosts_r( > > ????????char *cp, **alias; > > ????????int aliases, i, ret = HOST_NOT_FOUND; > > ? > > +???????/* Align to at least the size of a char * so we can put > > +??????? ? pointers in it. ?*/ > > +???????i = (unsigned long) buf % sizeof(char *); > > +???????i = (sizeof(char *) - i) % sizeof(char *); > > +???????if (buflen < i) > > +???????????????return ERANGE; > > +???????buf+=i; > > +???????buflen-=i; > > + > > considering buflen gets checked constantly before being utilized, i dont think > we need an additional check to see if it could possibly store a pointer. we > just need to make sure the adjustment alone doesnt cause size_t underflow. That's exactly what I just did, except for the spelling of the alignment; sizeof(size_t) is sufficient on all Linux platforms for everything that gethostbyname_r puts in the buffer. > i think this should be sufficient: > /* Make sure the incoming char * buffer is aligned enough to > * handle our random structures. This define is the same as we > * use for malloc alignment (which has same requirements). */ > i = (size_t)buf & __alignof__(double __attribute_aligned__ (sizeof(size_t))); > if (buflen < i) > return ERANGE; > buf += i; > buflen += i; - Why sizeof(size_t)? What does that have to do with anything, if you're already using __alignof__? - "(size_t) buf & 8" is not what you're trying to calculate, you need a -1. - buflen -= i, not plus -- Daniel Jacobowitz CodeSourcery From alec at sensi.org Mon Jan 7 07:29:43 2008 From: alec at sensi.org (Alexander Voropay) Date: Mon, 7 Jan 2008 18:29:43 +0300 Subject: mipsel memcpy & gcc3.4.6 In-Reply-To: <200801051125.09281.vapier@gentoo.org> References: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> <200801051125.09281.vapier@gentoo.org> Message-ID: <347d9b1b0801070729n573e6b1cia46d0e97fe16a0d9@mail.gmail.com> 2008/1/5, Mike Frysinger : > On Saturday 05 January 2008, Alexander Voropay wrote: > > Can anyone help with this issue ? > > > > I've opened a bug in the busybox tracking system: > > > > http://busybox.net/bugs/view.php?id=1894 > > i already told you it wasnt a bug in uClibc ... It seems, GCC 3.4.6 preprocessor supports ## concatenations incorrectly. I've took ENTRY definition from the "sysdeps.h" of the ia64/sysdeps.h It works. =============================================== --- libc/string/mips/sysdep.h.OLD 2008-01-07 18:17:44.165170520 +0300 +++ libc/string/mips/sysdep.h 2008-01-07 17:34:29.000000000 +0300 @@ -25,11 +25,18 @@ #include #include -#define ENTRY(name) \ - .globl name; \ - .align 2; \ - .ent name,0; \ - name##: +#ifdef __STDC__ +#define C_LABEL(name) name : +#else +#define C_LABEL(name) name/**/: +#endif + +#define ENTRY(name) \ + .text; \ + .align 2; \ + .ent name,0; \ + .globl name; \ + C_LABEL(name) #undef END #define END(function) \ =========================================== From drow at false.org Mon Jan 7 07:43:05 2008 From: drow at false.org (Daniel Jacobowitz) Date: Mon, 7 Jan 2008 10:43:05 -0500 Subject: mipsel memcpy & gcc3.4.6 In-Reply-To: <347d9b1b0801070729n573e6b1cia46d0e97fe16a0d9@mail.gmail.com> References: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> <200801051125.09281.vapier@gentoo.org> <347d9b1b0801070729n573e6b1cia46d0e97fe16a0d9@mail.gmail.com> Message-ID: <20080107154305.GA8069@caradoc.them.org> On Mon, Jan 07, 2008 at 06:29:43PM +0300, Alexander Voropay wrote: > It seems, GCC 3.4.6 preprocessor supports ## concatenations > incorrectly. I've took ENTRY definition from the "sysdeps.h" of the > ia64/sysdeps.h It works. name##: is incorrect. ## is supposed to be used between parts of a single pp-token; ":" is a token all by itself. -- Daniel Jacobowitz CodeSourcery From will.newton at gmail.com Mon Jan 7 07:45:34 2008 From: will.newton at gmail.com (Will Newton) Date: Mon, 7 Jan 2008 15:45:34 +0000 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) Message-ID: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> Hi Bernd, (I hope I got the right email address here) I noticed commit 20613 prepends an underscore to the symbol name passed to dlsym() if __UCLIBC_NO_UNDERSCORE__ is not defined. I was wondering if you could explain the rationale behind this change? I maintain a uClibc port for a similarly afflicted architecture and I am not sure whether or not this is the correct thing to do. For example there is now no way to lookup the symbol "foo" rather than "_foo" but that might not be seen as a problem. Is there a spec that requires dlsym() to behave this way? Thanks, From carmelo.amoroso at st.com Mon Jan 7 08:30:03 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Mon, 07 Jan 2008 17:30:03 +0100 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> Message-ID: <4782538B.3060602@st.com> Will Newton wrote: > Hi Bernd, > > (I hope I got the right email address here) > > I noticed commit 20613 prepends an underscore to the symbol name > passed to dlsym() if __UCLIBC_NO_UNDERSCORE__ is not defined. I was > wondering if you could explain the rationale behind this change? It seems to me the it's just the opposite.... +++ trunk/uClibc/ldso/include/dl-defs.h 2007-12-03 22:46:53 UTC (rev 20613) @@ -175,4 +175,10 @@ # define DL_MALLOC_ALIGN (__WORDSIZE / 8) #endif +#ifdef __UCLIBC_NO_UNDERSCORES__ +#define __C_SYMBOL_PREFIX__ "" +#else +#define __C_SYMBOL_PREFIX__ "_" +#endif + #endif /* _LD_DEFS_H */ or not? Carmelo From vapier at gentoo.org Mon Jan 7 08:36:01 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 7 Jan 2008 11:36:01 -0500 Subject: mipsel memcpy & gcc3.4.6 In-Reply-To: <20080107154305.GA8069@caradoc.them.org> References: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> <347d9b1b0801070729n573e6b1cia46d0e97fe16a0d9@mail.gmail.com> <20080107154305.GA8069@caradoc.them.org> Message-ID: <200801071136.01919.vapier@gentoo.org> On Monday 07 January 2008, Daniel Jacobowitz wrote: > On Mon, Jan 07, 2008 at 06:29:43PM +0300, Alexander Voropay wrote: > > It seems, GCC 3.4.6 preprocessor supports ## concatenations > > incorrectly. I've took ENTRY definition from the "sysdeps.h" of the > > ia64/sysdeps.h It works. > > name##: is incorrect. ## is supposed to be used between parts of a > single pp-token; ":" is a token all by itself. shouldnt gcc be uniformly barfing on this instead of sporadically ? should i open a gcc PR about gcc wrongly accepting name##: ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080107/7574d4c2/attachment.pgp From vapier at gentoo.org Mon Jan 7 08:39:39 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 7 Jan 2008 11:39:39 -0500 Subject: Alignment fixups for gethostbyname_r In-Reply-To: <20080107132229.GA31895@caradoc.them.org> References: <20071219165728.GA3828@caradoc.them.org> <200801060135.53689.vapier@gentoo.org> <20080107132229.GA31895@caradoc.them.org> Message-ID: <200801071139.40498.vapier@gentoo.org> On Monday 07 January 2008, Daniel Jacobowitz wrote: > On Sun, Jan 06, 2008 at 01:35:53AM -0500, Mike Frysinger wrote: > > On Wednesday 19 December 2007, Daniel Jacobowitz wrote: > > > --- libc/inet/resolv.c??(revision 189757) > > > +++ libc/inet/resolv.c??(local) > > > @@ -1534,6 +1534,15 @@ int attribute_hidden __read_etc_hosts_r( > > > ????????char *cp, **alias; > > > ????????int aliases, i, ret = HOST_NOT_FOUND; > > > ? > > > +???????/* Align to at least the size of a char * so we can put > > > +??????? ? pointers in it. ?*/ > > > +???????i = (unsigned long) buf % sizeof(char *); > > > +???????i = (sizeof(char *) - i) % sizeof(char *); > > > +???????if (buflen < i) > > > +???????????????return ERANGE; > > > +???????buf+=i; > > > +???????buflen-=i; > > > > considering buflen gets checked constantly before being utilized, i dont > > think we need an additional check to see if it could possibly store a > > pointer. we just need to make sure the adjustment alone doesnt cause > > size_t underflow. > > That's exactly what I just did, except for the spelling of the > alignment; sizeof(size_t) is sufficient on all Linux platforms for > everything that gethostbyname_r puts in the buffer. i misunderstood the purpose of the second assignment. i'll put together a test case and commit a fix ... > > i think this should be sufficient: > > /* Make sure the incoming char * buffer is aligned enough to > > * handle our random structures. This define is the same as we > > * use for malloc alignment (which has same requirements). */ > > i = (size_t)buf & __alignof__(double __attribute_aligned__ > > (sizeof(size_t))); if (buflen < i) > > return ERANGE; > > buf += i; > > buflen += i; > > - Why sizeof(size_t)? What does that have to do with anything, if > you're already using __alignof__? this is taken from the existing malloc code which takes into account different arch quirks for alignment > - "(size_t) buf & 8" is not what you're trying to calculate, you need > a -1. ah right, i thought you were after something else with the second line > - buflen -= i, not plus i pointed this typo out already ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080107/a001e445/attachment.pgp From drow at false.org Mon Jan 7 08:45:58 2008 From: drow at false.org (Daniel Jacobowitz) Date: Mon, 7 Jan 2008 11:45:58 -0500 Subject: mipsel memcpy & gcc3.4.6 In-Reply-To: <200801071136.01919.vapier@gentoo.org> References: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> <347d9b1b0801070729n573e6b1cia46d0e97fe16a0d9@mail.gmail.com> <20080107154305.GA8069@caradoc.them.org> <200801071136.01919.vapier@gentoo.org> Message-ID: <20080107164558.GA11992@caradoc.them.org> On Mon, Jan 07, 2008 at 11:36:01AM -0500, Mike Frysinger wrote: > On Monday 07 January 2008, Daniel Jacobowitz wrote: > > On Mon, Jan 07, 2008 at 06:29:43PM +0300, Alexander Voropay wrote: > > > It seems, GCC 3.4.6 preprocessor supports ## concatenations > > > incorrectly. I've took ENTRY definition from the "sysdeps.h" of the > > > ia64/sysdeps.h It works. > > > > name##: is incorrect. ## is supposed to be used between parts of a > > single pp-token; ":" is a token all by itself. > > shouldnt gcc be uniformly barfing on this instead of sporadically ? should i > open a gcc PR about gcc wrongly accepting name##: ? The current versions of GCC do exactly what the standard say they ought to: gq.c:2:1: error: pasting "name" and ":" does not give a valid preprocessing token -- Daniel Jacobowitz CodeSourcery From drow at false.org Mon Jan 7 08:46:56 2008 From: drow at false.org (Daniel Jacobowitz) Date: Mon, 7 Jan 2008 11:46:56 -0500 Subject: Alignment fixups for gethostbyname_r In-Reply-To: <200801071139.40498.vapier@gentoo.org> References: <20071219165728.GA3828@caradoc.them.org> <200801060135.53689.vapier@gentoo.org> <20080107132229.GA31895@caradoc.them.org> <200801071139.40498.vapier@gentoo.org> Message-ID: <20080107164656.GB11992@caradoc.them.org> On Mon, Jan 07, 2008 at 11:39:39AM -0500, Mike Frysinger wrote: > i misunderstood the purpose of the second assignment. i'll put together a > test case and commit a fix ... Thank you! > > - buflen -= i, not plus > > i pointed this typo out already ... Sorry, stray list filters. -- Daniel Jacobowitz CodeSourcery From vapier at gentoo.org Mon Jan 7 09:00:20 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 7 Jan 2008 12:00:20 -0500 Subject: mipsel memcpy & gcc3.4.6 In-Reply-To: <20080107164558.GA11992@caradoc.them.org> References: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> <200801071136.01919.vapier@gentoo.org> <20080107164558.GA11992@caradoc.them.org> Message-ID: <200801071200.21425.vapier@gentoo.org> On Monday 07 January 2008, Daniel Jacobowitz wrote: > On Mon, Jan 07, 2008 at 11:36:01AM -0500, Mike Frysinger wrote: > > On Monday 07 January 2008, Daniel Jacobowitz wrote: > > > On Mon, Jan 07, 2008 at 06:29:43PM +0300, Alexander Voropay wrote: > > > > It seems, GCC 3.4.6 preprocessor supports ## concatenations > > > > incorrectly. I've took ENTRY definition from the "sysdeps.h" of the > > > > ia64/sysdeps.h It works. > > > > > > name##: is incorrect. ## is supposed to be used between parts of a > > > single pp-token; ":" is a token all by itself. > > > > shouldnt gcc be uniformly barfing on this instead of sporadically ? > > should i open a gcc PR about gcc wrongly accepting name##: ? > > The current versions of GCC do exactly what the standard say they ought > to: > > gq.c:2:1: error: pasting "name" and ":" does not give a valid > preprocessing token what are you defining as "current" ? the current release (4.2.2) certainly accepts it as does a large majority of compiler versions (going by the fact that this is the first such bug report after using this code for quite a while): $ cat test.S #define foo(name) name##: foo(f) $ gcc -c test.S $ gcc --version gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080107/a6eeb401/attachment.pgp From drow at false.org Mon Jan 7 09:11:37 2008 From: drow at false.org (Daniel Jacobowitz) Date: Mon, 7 Jan 2008 12:11:37 -0500 Subject: mipsel memcpy & gcc3.4.6 In-Reply-To: <200801071200.21425.vapier@gentoo.org> References: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> <200801071136.01919.vapier@gentoo.org> <20080107164558.GA11992@caradoc.them.org> <200801071200.21425.vapier@gentoo.org> Message-ID: <20080107171137.GA13327@caradoc.them.org> On Mon, Jan 07, 2008 at 12:00:20PM -0500, Mike Frysinger wrote: > > The current versions of GCC do exactly what the standard say they ought > > to: > > > > gq.c:2:1: error: pasting "name" and ":" does not give a valid > > preprocessing token > > what are you defining as "current" ? the current release (4.2.2) certainly > accepts it as does a large majority of compiler versions (going by the fact > that this is the first such bug report after using this code for quite a > while): > $ cat test.S > #define foo(name) name##: > foo(f) > $ gcc -c test.S > $ gcc --version > gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0) Sorry, I forgot that it depends what language you're compiling. It's accepted for assembly, but not for C. There's special cases for # (stringify) too. I don't know why. -- Daniel Jacobowitz CodeSourcery From alec at sensi.org Mon Jan 7 09:35:06 2008 From: alec at sensi.org (Alexander Voropay) Date: Mon, 7 Jan 2008 20:35:06 +0300 Subject: mipsel memcpy & gcc3.4.6 In-Reply-To: <200801071200.21425.vapier@gentoo.org> References: <347d9b1b0801050727m3ce2dbabr7823aa95e0708046@mail.gmail.com> <200801071136.01919.vapier@gentoo.org> <20080107164558.GA11992@caradoc.them.org> <200801071200.21425.vapier@gentoo.org> Message-ID: <347d9b1b0801070935i25543437vfc355d6be8c08631@mail.gmail.com> > what are you defining as "current" ? the current release (4.2.2) certainly > accepts it as does a large majority of compiler versions (going by the fact > that this is the first such bug report after using this code for quite a > while): As you told, GCC 3.4.6 accepts name##: w/o -std=gnu99 $ cat test.S #define foo(name) name##: foo(f) $ mipsel-linux-uclibc-gcc -c test.S $ $mipsel-linux-uclibc-gcc -c -std=gnu99 test.S test.S:3:1: pasting "f" and ":" does not give a valid preprocessing token $ $mipsel-linux-uclibc-gcc --version mipsel-linux-uclibc-gcc (GCC) 3.4.6 From will.newton at gmail.com Tue Jan 8 01:54:22 2008 From: will.newton at gmail.com (Will Newton) Date: Tue, 8 Jan 2008 09:54:22 +0000 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <4782538B.3060602@st.com> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <4782538B.3060602@st.com> Message-ID: <87a5b0800801080154v4ba098d9ld16eb7175e16e55b@mail.gmail.com> On Jan 7, 2008 4:30 PM, Carmelo AMOROSO wrote: > Will Newton wrote: > > Hi Bernd, > > > > (I hope I got the right email address here) > > > > I noticed commit 20613 prepends an underscore to the symbol name > > passed to dlsym() if __UCLIBC_NO_UNDERSCORE__ is not defined. I was > > wondering if you could explain the rationale behind this change? > It seems to me the it's just the opposite.... Hmm, no, I think what I said is correct. If no underscores is NOT defined then we prepend the underscore. > +++ trunk/uClibc/ldso/include/dl-defs.h 2007-12-03 22:46:53 UTC (rev 20613) > @@ -175,4 +175,10 @@ > # define DL_MALLOC_ALIGN (__WORDSIZE / 8) > #endif > > +#ifdef __UCLIBC_NO_UNDERSCORES__ > +#define __C_SYMBOL_PREFIX__ "" > +#else > +#define __C_SYMBOL_PREFIX__ "_" > +#endif > + > #endif /* _LD_DEFS_H */ > > or not? > Carmelo > From lethal at linux-sh.org Tue Jan 8 02:14:52 2008 From: lethal at linux-sh.org (Paul Mundt) Date: Tue, 8 Jan 2008 19:14:52 +0900 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <87a5b0800801080154v4ba098d9ld16eb7175e16e55b@mail.gmail.com> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <4782538B.3060602@st.com> <87a5b0800801080154v4ba098d9ld16eb7175e16e55b@mail.gmail.com> Message-ID: <20080108101452.GA25218@linux-sh.org> On Tue, Jan 08, 2008 at 09:54:22AM +0000, Will Newton wrote: > On Jan 7, 2008 4:30 PM, Carmelo AMOROSO wrote: > > Will Newton wrote: > > > Hi Bernd, > > > > > > (I hope I got the right email address here) > > > > > > I noticed commit 20613 prepends an underscore to the symbol name > > > passed to dlsym() if __UCLIBC_NO_UNDERSCORE__ is not defined. I was > > > wondering if you could explain the rationale behind this change? > > It seems to me the it's just the opposite.... > > Hmm, no, I think what I said is correct. If no underscores is NOT > defined then we prepend the underscore. > You both appear to be in agreement on the result. The patch does precisely what is described: > > +++ trunk/uClibc/ldso/include/dl-defs.h 2007-12-03 22:46:53 UTC (rev 20613) > > @@ -175,4 +175,10 @@ > > # define DL_MALLOC_ALIGN (__WORDSIZE / 8) > > #endif > > > > +#ifdef __UCLIBC_NO_UNDERSCORES__ > > +#define __C_SYMBOL_PREFIX__ "" > > +#else > > +#define __C_SYMBOL_PREFIX__ "_" > > +#endif > > + > > #endif /* _LD_DEFS_H */ > > Additionally, this sort of backwards logic is precisely why having inverted ifdef logic is absolute brain-damage. #ifndef __UCLIBC_UNDERSCORES__ is infinitely more readable, even though an #ifdef __UCLIBC_HELP_MY_TOOLCHAIN_SUCKS__ would be more intuitive at first glance (and more fitting, for those insisting on using -elf toolchains). It's like SYMBOL_PREFIX() hell all over again.. From will.newton at gmail.com Tue Jan 8 03:22:01 2008 From: will.newton at gmail.com (Will Newton) Date: Tue, 8 Jan 2008 11:22:01 +0000 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <20080108101452.GA25218@linux-sh.org> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <4782538B.3060602@st.com> <87a5b0800801080154v4ba098d9ld16eb7175e16e55b@mail.gmail.com> <20080108101452.GA25218@linux-sh.org> Message-ID: <87a5b0800801080322l27da83baif03b39ca5a1d66bb@mail.gmail.com> On Jan 8, 2008 10:14 AM, Paul Mundt wrote: > > Hmm, no, I think what I said is correct. If no underscores is NOT > > defined then we prepend the underscore. > > > You both appear to be in agreement on the result. The patch does > precisely what is described: Incidentally the patch I refer to is not the posted one, the patch I was referring to is this one: http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/ldso/libdl/libdl.c?rev=20613&r1=20612&r2=20613 > > > +++ trunk/uClibc/ldso/include/dl-defs.h 2007-12-03 22:46:53 UTC (rev 20613) > > > @@ -175,4 +175,10 @@ > > > # define DL_MALLOC_ALIGN (__WORDSIZE / 8) > > > #endif > > > > > > +#ifdef __UCLIBC_NO_UNDERSCORES__ > > > +#define __C_SYMBOL_PREFIX__ "" > > > +#else > > > +#define __C_SYMBOL_PREFIX__ "_" > > > +#endif > > > + > > > #endif /* _LD_DEFS_H */ > > > > > Additionally, this sort of backwards logic is precisely why having > inverted ifdef logic is absolute brain-damage. Agreed. > #ifndef __UCLIBC_UNDERSCORES__ is infinitely more readable, even though > an #ifdef __UCLIBC_HELP_MY_TOOLCHAIN_SUCKS__ would be more intuitive at > first glance (and more fitting, for those insisting on using -elf > toolchains). It's like SYMBOL_PREFIX() hell all over again.. Unfortunately it's a battle I have fought and lost for our toolchain. From vapier at gentoo.org Tue Jan 8 07:44:52 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 10:44:52 -0500 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <87a5b0800801080322l27da83baif03b39ca5a1d66bb@mail.gmail.com> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <20080108101452.GA25218@linux-sh.org> <87a5b0800801080322l27da83baif03b39ca5a1d66bb@mail.gmail.com> Message-ID: <200801081044.53538.vapier@gentoo.org> On Tuesday 08 January 2008, Will Newton wrote: > On Jan 8, 2008 10:14 AM, Paul Mundt wrote: > > > Hmm, no, I think what I said is correct. If no underscores is NOT > > > defined then we prepend the underscore. > > > > You both appear to be in agreement on the result. The patch does > > precisely what is described: > > Incidentally the patch I refer to is not the posted one, the patch I > was referring to is this one: > > http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/ldso/libdl/lib >dl.c?rev=20613&r1=20612&r2=20613 the change looks correct to me, and it works on Blackfin, so ... i386/bits:#define __UCLIBC_NO_UNDERSCORES__ libdl code: #ifndef __UCLIBC_NO_UNDERSCORES__ #else #endif so on i386, the code path which prepends _ is not taken > > > > +++ trunk/uClibc/ldso/include/dl-defs.h 2007-12-03 22:46:53 UTC (rev > > > > 20613) @@ -175,4 +175,10 @@ > > > > # define DL_MALLOC_ALIGN (__WORDSIZE / 8) > > > > #endif > > > > > > > > +#ifdef __UCLIBC_NO_UNDERSCORES__ > > > > +#define __C_SYMBOL_PREFIX__ "" > > > > +#else > > > > +#define __C_SYMBOL_PREFIX__ "_" > > > > +#endif > > > > + > > > > #endif /* _LD_DEFS_H */ > > > > Additionally, this sort of backwards logic is precisely why having > > inverted ifdef logic is absolute brain-damage. > > Agreed. i'll drop the _NO_ and invert the ifdefs, but that doesnt involve actually changing any of the logic of how things work which still means the current code is correct -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080108/9ab2b2fa/attachment.pgp From vapier at gentoo.org Tue Jan 8 07:55:32 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 10:55:32 -0500 Subject: svn commit: trunk/uClibc In-Reply-To: <20080108084526.C8F9612C59D@busybox.net> References: <20080108084526.C8F9612C59D@busybox.net> Message-ID: <200801081055.33344.vapier@gentoo.org> On Tuesday 08 January 2008, lethal at uclibc.org wrote: > Author: lethal > Date: 2008-01-08 00:45:26 -0800 (Tue, 08 Jan 2008) > New Revision: 20817 > > Log: > sh64 uses a 32-bit ABI, don't bother with lib64 silliness. > > LIBC := libc > SHARED_MAJORNAME := $(LIBC).so.$(MAJOR_VERSION) > -ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 mips64 powerpc64 s390x > sh64 sparc64 x86_64 ),) +ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 > mips64 powerpc64 s390x sparc64 x86_64 ),) UCLIBC_LDSO_NAME := ld64-uClibc > else > UCLIBC_LDSO_NAME := ld-uClibc we dont actually do any lib64 crap in uClibc ... the only thing this does is change the default ldso filename so that on systems with multiple ABIs, you can install both side by side ... but really, this needs to match whatever gcc is doing, and it has been setup to use ld64-uClibc as its "LINKER64". now that i glance at gcc/config/sh/linux.h, it seems the sh ports needs to be fixed to use LINUX_DYNAMIC_LINKER in its default specs ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080108/389abd46/attachment.pgp From will.newton at gmail.com Tue Jan 8 07:58:00 2008 From: will.newton at gmail.com (Will Newton) Date: Tue, 8 Jan 2008 15:58:00 +0000 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <200801081044.53538.vapier@gentoo.org> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <20080108101452.GA25218@linux-sh.org> <87a5b0800801080322l27da83baif03b39ca5a1d66bb@mail.gmail.com> <200801081044.53538.vapier@gentoo.org> Message-ID: <87a5b0800801080758w4605b121oebe0146567b1928a@mail.gmail.com> On Jan 8, 2008 3:44 PM, Mike Frysinger wrote: > > http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/ldso/libdl/lib > >dl.c?rev=20613&r1=20612&r2=20613 > > the change looks correct to me, and it works on Blackfin, so ... > > i386/bits:#define __UCLIBC_NO_UNDERSCORES__ > libdl code: > #ifndef __UCLIBC_NO_UNDERSCORES__ > > #else > > #endif > > so on i386, the code path which prepends _ is not taken Agreed, my question is whether or not adding the underscore is the correct thing to do even if your architecture prepends an underscore to symbol names? Is there a particular reason why this was done for Blackfin, to make a particular app work? I am trying to find out what the correct behaviour of dlsym is, for example does it behave like this on other Unixes that have leading underscores on symbols. From drow at false.org Tue Jan 8 08:06:05 2008 From: drow at false.org (Daniel Jacobowitz) Date: Tue, 8 Jan 2008 11:06:05 -0500 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <87a5b0800801080758w4605b121oebe0146567b1928a@mail.gmail.com> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <20080108101452.GA25218@linux-sh.org> <87a5b0800801080322l27da83baif03b39ca5a1d66bb@mail.gmail.com> <200801081044.53538.vapier@gentoo.org> <87a5b0800801080758w4605b121oebe0146567b1928a@mail.gmail.com> Message-ID: <20080108160605.GA23807@caradoc.them.org> On Tue, Jan 08, 2008 at 03:58:00PM +0000, Will Newton wrote: > Agreed, my question is whether or not adding the underscore is the > correct thing to do even if your architecture prepends an underscore > to symbol names? Is there a particular reason why this was done for > Blackfin, to make a particular app work? I am trying to find out what > the correct behaviour of dlsym is, for example does it behave like > this on other Unixes that have leading underscores on symbols. There are pretty much no Unixes that do this; a few embedded Linux ports are the only exceptions I've ever encountered. If you have underscores, dlsym had better know about it, or cross-platform code will break. Consider dlsym (libc_handle, "printf"); every caller should not need to know about _printf. -- Daniel Jacobowitz CodeSourcery From will.newton at gmail.com Tue Jan 8 08:17:02 2008 From: will.newton at gmail.com (Will Newton) Date: Tue, 8 Jan 2008 16:17:02 +0000 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <20080108160605.GA23807@caradoc.them.org> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <20080108101452.GA25218@linux-sh.org> <87a5b0800801080322l27da83baif03b39ca5a1d66bb@mail.gmail.com> <200801081044.53538.vapier@gentoo.org> <87a5b0800801080758w4605b121oebe0146567b1928a@mail.gmail.com> <20080108160605.GA23807@caradoc.them.org> Message-ID: <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> On Jan 8, 2008 4:06 PM, Daniel Jacobowitz wrote: > On Tue, Jan 08, 2008 at 03:58:00PM +0000, Will Newton wrote: > > Agreed, my question is whether or not adding the underscore is the > > correct thing to do even if your architecture prepends an underscore > > to symbol names? Is there a particular reason why this was done for > > Blackfin, to make a particular app work? I am trying to find out what > > the correct behaviour of dlsym is, for example does it behave like > > this on other Unixes that have leading underscores on symbols. > > There are pretty much no Unixes that do this; a few embedded Linux > ports are the only exceptions I've ever encountered. I think I got the impression from the Levine "Linkers and Loaders" book (my copy of which seems to have vanished) that prepending an underscore to symbol names was common practice. Perhaps it was an a.out thing, that's rather before my time though... > If you have underscores, dlsym had better know about it, or > cross-platform code will break. Consider dlsym (libc_handle, > "printf"); every caller should not need to know about _printf. Thanks for clearing that up. My concern is that I've never seen this documented anywhere, but it does seem to be something of a corner case. From drow at false.org Tue Jan 8 08:29:58 2008 From: drow at false.org (Daniel Jacobowitz) Date: Tue, 8 Jan 2008 11:29:58 -0500 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <20080108101452.GA25218@linux-sh.org> <87a5b0800801080322l27da83baif03b39ca5a1d66bb@mail.gmail.com> <200801081044.53538.vapier@gentoo.org> <87a5b0800801080758w4605b121oebe0146567b1928a@mail.gmail.com> <20080108160605.GA23807@caradoc.them.org> <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> Message-ID: <20080108162958.GA25170@caradoc.them.org> On Tue, Jan 08, 2008 at 04:17:02PM +0000, Will Newton wrote: > On Jan 8, 2008 4:06 PM, Daniel Jacobowitz wrote: > > On Tue, Jan 08, 2008 at 03:58:00PM +0000, Will Newton wrote: > > > Agreed, my question is whether or not adding the underscore is the > > > correct thing to do even if your architecture prepends an underscore > > > to symbol names? Is there a particular reason why this was done for > > > Blackfin, to make a particular app work? I am trying to find out what > > > the correct behaviour of dlsym is, for example does it behave like > > > this on other Unixes that have leading underscores on symbols. > > > > There are pretty much no Unixes that do this; a few embedded Linux > > ports are the only exceptions I've ever encountered. > > I think I got the impression from the Levine "Linkers and Loaders" > book (my copy of which seems to have vanished) that prepending an > underscore to symbol names was common practice. Perhaps it was an > a.out thing, that's rather before my time though... Not on modern Unixes, anyway. Some *-elf targets do, and more *-coff and *-aout targets. As I understand it, the only reasons are habit and to accomodate an assembler syntax which makes symbol names ambiguous with something else (e.g. register names). If it's a habit, expect everyone to have the habit; if it's to accomodate the assembler, expect everyone to accomodate the assembler. So there shouldn't be any symbols without the underscore. -- Daniel Jacobowitz CodeSourcery From vapier at gentoo.org Tue Jan 8 08:54:29 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 11:54:29 -0500 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <20080108162958.GA25170@caradoc.them.org> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> <20080108162958.GA25170@caradoc.them.org> Message-ID: <200801081154.30422.vapier@gentoo.org> On Tuesday 08 January 2008, Daniel Jacobowitz wrote: > On Tue, Jan 08, 2008 at 04:17:02PM +0000, Will Newton wrote: > > On Jan 8, 2008 4:06 PM, Daniel Jacobowitz wrote: > > > On Tue, Jan 08, 2008 at 03:58:00PM +0000, Will Newton wrote: > > > > Agreed, my question is whether or not adding the underscore is the > > > > correct thing to do even if your architecture prepends an underscore > > > > to symbol names? Is there a particular reason why this was done for > > > > Blackfin, to make a particular app work? I am trying to find out what > > > > the correct behaviour of dlsym is, for example does it behave like > > > > this on other Unixes that have leading underscores on symbols. > > > > > > There are pretty much no Unixes that do this; a few embedded Linux > > > ports are the only exceptions I've ever encountered. > > > > I think I got the impression from the Levine "Linkers and Loaders" > > book (my copy of which seems to have vanished) that prepending an > > underscore to symbol names was common practice. Perhaps it was an > > a.out thing, that's rather before my time though... > > Not on modern Unixes, anyway. Some *-elf targets do, and more *-coff > and *-aout targets. > > As I understand it, the only reasons are habit and to accomodate an > assembler syntax which makes symbol names ambiguous with something > else (e.g. register names). If it's a habit, expect everyone to have > the habit; if it's to accomodate the assembler, expect everyone to > accomodate the assembler. So there shouldn't be any symbols without > the underscore. the Blackfin reason was backwards compatibility with existing propriety toolchains (and we didnt have input for those toolchains at their time of creation). at this point, we've screwed ourselves into an ABI corner, so there probably wont be a way to get ourselves out. unless another Blackfin comes along that is not opcode compatible ... and we feel like shouldering the development burden. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080108/602936b5/attachment.pgp From vapier at gentoo.org Tue Jan 8 08:58:00 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 11:58:00 -0500 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <20080108160605.GA23807@caradoc.them.org> <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> Message-ID: <200801081158.01711.vapier@gentoo.org> On Tuesday 08 January 2008, Will Newton wrote: > On Jan 8, 2008 4:06 PM, Daniel Jacobowitz wrote: > > On Tue, Jan 08, 2008 at 03:58:00PM +0000, Will Newton wrote: > > > Agreed, my question is whether or not adding the underscore is the > > > correct thing to do even if your architecture prepends an underscore > > > to symbol names? Is there a particular reason why this was done for > > > Blackfin, to make a particular app work? I am trying to find out what > > > the correct behaviour of dlsym is, for example does it behave like > > > this on other Unixes that have leading underscores on symbols. > > > > There are pretty much no Unixes that do this; a few embedded Linux > > ports are the only exceptions I've ever encountered. > > I think I got the impression from the Levine "Linkers and Loaders" > book (my copy of which seems to have vanished) that prepending an > underscore to symbol names was common practice. Perhaps it was an > a.out thing, that's rather before my time though... an excellent book that could do with some freshening up to things done $today ... but until that happens, you'll have to mentally tweak the details so they apply exactly to today's conventions. > > If you have underscores, dlsym had better know about it, or > > cross-platform code will break. Consider dlsym (libc_handle, > > "printf"); every caller should not need to know about _printf. > > Thanks for clearing that up. My concern is that I've never seen this > documented anywhere, but it does seem to be something of a corner > case. as Daniel indicates, ABI symbol prefixes are the way of the dinosaur, so this sort of thing doesnt get documented. but if you apply some grease to the concepts, dlsym() looks for C symbols which means it needs to find symbols named exactly the same as the C compiler produces -- ABI symbol prefixes included. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080108/9e118086/attachment.pgp From drow at false.org Tue Jan 8 09:04:37 2008 From: drow at false.org (Daniel Jacobowitz) Date: Tue, 8 Jan 2008 12:04:37 -0500 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <200801081154.30422.vapier@gentoo.org> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> <20080108162958.GA25170@caradoc.them.org> <200801081154.30422.vapier@gentoo.org> Message-ID: <20080108170437.GA27424@caradoc.them.org> On Tue, Jan 08, 2008 at 11:54:29AM -0500, Mike Frysinger wrote: > the Blackfin reason was backwards compatibility with existing propriety > toolchains (and we didnt have input for those toolchains at their time of > creation). at this point, we've screwed ourselves into an ABI corner, so > there probably wont be a way to get ourselves out. unless another Blackfin > comes along that is not opcode compatible ... and we feel like shouldering > the development burden. That's what I meant by "habit" :-) -- Daniel Jacobowitz CodeSourcery From vapier at gentoo.org Tue Jan 8 09:06:47 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 12:06:47 -0500 Subject: uClibc and expected versions of usable gcc Message-ID: <200801081206.47766.vapier@gentoo.org> at this time, i'd consider gcc-3.4.6 the oldest version worth using with uClibc. that means it's the oldest version i'd consider adding source code tweaks to work around gcc bugs. for older versions of gcc, if uClibc fails to build for you due to a bug in the compiler, the answer is upgrade your gcc, sorry. any comments/thoughts/inputs/whatever ? ready set fight -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080108/0325eadd/attachment.pgp From lethal at linux-sh.org Tue Jan 8 09:30:33 2008 From: lethal at linux-sh.org (Paul Mundt) Date: Wed, 9 Jan 2008 02:30:33 +0900 Subject: svn commit: trunk/uClibc In-Reply-To: <200801081055.33344.vapier@gentoo.org> References: <20080108084526.C8F9612C59D@busybox.net> <200801081055.33344.vapier@gentoo.org> Message-ID: <20080108173033.GA25485@linux-sh.org> On Tue, Jan 08, 2008 at 10:55:32AM -0500, Mike Frysinger wrote: > On Tuesday 08 January 2008, lethal at uclibc.org wrote: > > Author: lethal > > Date: 2008-01-08 00:45:26 -0800 (Tue, 08 Jan 2008) > > New Revision: 20817 > > > > Log: > > sh64 uses a 32-bit ABI, don't bother with lib64 silliness. > > > > LIBC := libc > > SHARED_MAJORNAME := $(LIBC).so.$(MAJOR_VERSION) > > -ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 mips64 powerpc64 s390x > > sh64 sparc64 x86_64 ),) +ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 > > mips64 powerpc64 s390x sparc64 x86_64 ),) UCLIBC_LDSO_NAME := ld64-uClibc > > else > > UCLIBC_LDSO_NAME := ld-uClibc > > we dont actually do any lib64 crap in uClibc ... the only thing this does is > change the default ldso filename so that on systems with multiple ABIs, you > can install both side by side ... but really, this needs to match whatever > gcc is doing, and it has been setup to use ld64-uClibc as its "LINKER64". > It was the naming ambiguity I was referring to in the commit log. The ld64 thing is grossly misleading on a 32-bit ABI. > now that i glance at gcc/config/sh/linux.h, it seems the sh ports needs to be > fixed to use LINUX_DYNAMIC_LINKER in its default specs ... Thanks for pointing that out, I'll take a look at it in the morning. From lethal at linux-sh.org Tue Jan 8 09:43:09 2008 From: lethal at linux-sh.org (Paul Mundt) Date: Wed, 9 Jan 2008 02:43:09 +0900 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <20080108101452.GA25218@linux-sh.org> <87a5b0800801080322l27da83baif03b39ca5a1d66bb@mail.gmail.com> <200801081044.53538.vapier@gentoo.org> <87a5b0800801080758w4605b121oebe0146567b1928a@mail.gmail.com> <20080108160605.GA23807@caradoc.them.org> <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> Message-ID: <20080108174309.GA27187@linux-sh.org> On Tue, Jan 08, 2008 at 04:17:02PM +0000, Will Newton wrote: > On Jan 8, 2008 4:06 PM, Daniel Jacobowitz wrote: > > On Tue, Jan 08, 2008 at 03:58:00PM +0000, Will Newton wrote: > > > Agreed, my question is whether or not adding the underscore is the > > > correct thing to do even if your architecture prepends an underscore > > > to symbol names? Is there a particular reason why this was done for > > > Blackfin, to make a particular app work? I am trying to find out what > > > the correct behaviour of dlsym is, for example does it behave like > > > this on other Unixes that have leading underscores on symbols. > > > > There are pretty much no Unixes that do this; a few embedded Linux > > ports are the only exceptions I've ever encountered. > > I think I got the impression from the Levine "Linkers and Loaders" > book (my copy of which seems to have vanished) that prepending an > underscore to symbol names was common practice. Perhaps it was an > a.out thing, that's rather before my time though... > It's something that a number of the -elf target do, or used to do. Most platforms use -linux targets which don't do this, so it hasn't been a big deal in practice. The use of -elf toolchains for building the kernel and things of that nature were far more prevalent in the olden days, hence the SYMBOL_PREFIX() debacle. It's especially a very common thing on the mmuless platforms, but likewise, this is quickly turning in to legacy behaviour (or just a bare metal target). It's preferable to just get a real toolchain, as anyone that remembers what the old system call tables used to look like can attest. Most architectures have given up on uglifying the code in order to try and accomodate these fringe toolchains -- and subsequently, most of the support never made it out of the 2.4 kernels, forcing people to standardize on the -linux variants anyways. This doesn't seem like an ureasonable direction to start pushing the libc, either. From alec at sensi.org Tue Jan 8 09:52:04 2008 From: alec at sensi.org (Alexander Voropay) Date: Tue, 8 Jan 2008 20:52:04 +0300 Subject: uClibc and expected versions of usable gcc In-Reply-To: <200801081206.47766.vapier@gentoo.org> References: <200801081206.47766.vapier@gentoo.org> Message-ID: <347d9b1b0801080952odf01e86v839d1edc960f193d@mail.gmail.com> > at this time, i'd consider gcc-3.4.6 the oldest version worth using with > uClibc. With this small patch GCC 3.4.6 works for me. Is it possible to make it configurable for GCC3 ? =============================== --- Rules.mak.OLD 2008-01-08 17:49:46.000000000 +0300 +++ Rules.mak 2008-01-08 17:50:05.000000000 +0300 @@ -399,7 +399,7 @@ CFLAGS += -DSTATIC endif -CFLAGS += $(call check_gcc,-std=gnu99,) +CFLAGS += $(call check_gcc,) LDFLAGS_NOSTRIP:=$(CPU_LDFLAGS-y) -shared --warn-common --warn-once -z combreloc # binutils-2.16.1 warns about ignored sections, 2.16.91.0.3 and newer are ok ================================ From vapier at gentoo.org Tue Jan 8 10:27:21 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 13:27:21 -0500 Subject: uClibc and expected versions of usable gcc In-Reply-To: <347d9b1b0801080952odf01e86v839d1edc960f193d@mail.gmail.com> References: <200801081206.47766.vapier@gentoo.org> <347d9b1b0801080952odf01e86v839d1edc960f193d@mail.gmail.com> Message-ID: <200801081327.22281.vapier@gentoo.org> On Tuesday 08 January 2008, Alexander Voropay wrote: > > at this time, i'd consider gcc-3.4.6 the oldest version worth using with > > uClibc. > > With this small patch GCC 3.4.6 works for me. > > Is it possible to make it configurable for GCC3 ? the size of a patch does not imply its correctness. we certainly do not want to go dropping -std=gnu99 for any toolchain version. the macro in question will be tweaked with a comment separator or whitespace. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080108/31c1f434/attachment.pgp From vapier at gentoo.org Tue Jan 8 10:31:23 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 13:31:23 -0500 Subject: uClibc and expected versions of usable gcc In-Reply-To: <347d9b1b0801080952odf01e86v839d1edc960f193d@mail.gmail.com> References: <200801081206.47766.vapier@gentoo.org> <347d9b1b0801080952odf01e86v839d1edc960f193d@mail.gmail.com> Message-ID: <200801081331.24042.vapier@gentoo.org> On Tuesday 08 January 2008, Alexander Voropay wrote: > > at this time, i'd consider gcc-3.4.6 the oldest version worth using with > > uClibc. > > With this small patch GCC 3.4.6 works for me. also, this patch is off-topic for the thread. it is about whether we want to support older versions, and that is all. please keep things on-topic. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080108/78910ca6/attachment-0001.pgp From vapier at gentoo.org Tue Jan 8 11:23:54 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 14:23:54 -0500 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <200801081044.53538.vapier@gentoo.org> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <87a5b0800801080322l27da83baif03b39ca5a1d66bb@mail.gmail.com> <200801081044.53538.vapier@gentoo.org> Message-ID: <200801081423.55197.vapier@gentoo.org> On Tuesday 08 January 2008, Mike Frysinger wrote: > On Tuesday 08 January 2008, Will Newton wrote: > > On Jan 8, 2008 10:14 AM, Paul Mundt wrote: > > > > > +++ trunk/uClibc/ldso/include/dl-defs.h 2007-12-03 22:46:53 UTC > > > > > (rev 20613) @@ -175,4 +175,10 @@ > > > > > # define DL_MALLOC_ALIGN (__WORDSIZE / 8) > > > > > #endif > > > > > > > > > > +#ifdef __UCLIBC_NO_UNDERSCORES__ > > > > > +#define __C_SYMBOL_PREFIX__ "" > > > > > +#else > > > > > +#define __C_SYMBOL_PREFIX__ "_" > > > > > +#endif > > > > > + > > > > > #endif /* _LD_DEFS_H */ > > > > > > Additionally, this sort of backwards logic is precisely why having > > > inverted ifdef logic is absolute brain-damage. > > > > Agreed. > > i'll drop the _NO_ and invert the ifdefs, but that doesnt involve actually > changing any of the logic of how things work which still means the current > code is correct i'll just go ahead and blame glibc here. its configure.in sets up NO_UNDERSCORE which proliferated into the uClibc __UCLIBC_NO_UNDERSCORES__. not Bernd's fault for rolling with this ;). -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080108/44dd086f/attachment.pgp From peter.kjellerstedt at axis.com Tue Jan 8 11:38:22 2008 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 8 Jan 2008 20:38:22 +0100 Subject: uClibc and expected versions of usable gcc References: <200801081206.47766.vapier@gentoo.org> Message-ID: <50BF37ECE4954A4BA18C08D0C2CF88CB03C9FC3F@exmail1.se.axis.com> > -----Original Message----- > From: uclibc-bounces at uclibc.org > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Mike Frysinger > Sent: den 8 januari 2008 18:07 > To: uclibc at uclibc.org > Subject: uClibc and expected versions of usable gcc > > at this time, i'd consider gcc-3.4.6 the oldest version worth > using with uClibc. that means it's the oldest version i'd > consider adding source code tweaks to work around gcc bugs. > for older versions of gcc, if uClibc fails to build for you > due to a bug in the compiler, the answer is upgrade your gcc, > sorry. > > any comments/thoughts/inputs/whatever ? ready set fight > -mike Well, for what it is worth, we are currently stuck on version 3.2.1 for CRIS, and that is not likely to change in the near future. //Peter From robert.dodier at gmail.com Tue Jan 8 11:45:11 2008 From: robert.dodier at gmail.com (Robert Dodier) Date: Tue, 8 Jan 2008 12:45:11 -0700 Subject: "Can't modify text section" error trying to load .so library Message-ID: Hello, This is a bit of a long shot. If anyone has some info I'll be very grateful. I am trying to run IBM J9 JVM on a Gumstix, which is an ARM cpu + Linux device. The C library is uClibc. When I try to execute J9, I get a message "Can't modify libj9vm23.so text section". The message appears to originate from uClibc/ldso/ldso/dl-elf.c. From vapier at gentoo.org Tue Jan 8 16:46:21 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 19:46:21 -0500 Subject: "Can't modify text section" error trying to load .so library In-Reply-To: References: Message-ID: <200801081946.22346.vapier@gentoo.org> On Tuesday 08 January 2008, Robert Dodier wrote: > I am trying to run IBM J9 JVM on a Gumstix, which is an ARM cpu + > Linux device. The C library is uClibc. When I try to execute J9, > I get a message "Can't modify libj9vm23.so text section". > The message appears to originate from uClibc/ldso/ldso/dl-elf.c. > > From browsing the web it appears the immediate cause of the > error is that some part of the .so library was not compiled w/ -fPIC. > Unfortunately I don't have the source code to recompile it. > Is there something I can do with the library as it stands? > e.g. environment settings, modify the .so library somehow? it is not something you can do without the source. well, i guess if you spent enough time reverse engineering the code and rewriting the assembly by hand, anything is possible ... as you've found out, uClibc rejects TEXTRELs by default in shared code because this means the code is no longer shared ... and that's sort of the point of having the shared object in the first place. > I see the error message is within the else part of > #ifndef __FORCE_SHAREABLE_TEXT_SEGMENTS__. > If I undefine that and recompile uClibc, I guess it would disable the > error message. Could I expect uClibc to generally work OK with > that undefined? it's a uClibc configure option, you do not need to modify the source code. if you allow TEXTRELs in shared objects, then this should not affect any shared objects that are compiled correctly in any way. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080108/de0cebd1/attachment.pgp From rgetz at blackfin.uclinux.org Tue Jan 8 20:18:15 2008 From: rgetz at blackfin.uclinux.org (Robin Getz) Date: Tue, 8 Jan 2008 23:18:15 -0500 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <20080108174309.GA27187@linux-sh.org> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <87a5b0800801080817k36990ad8pd782abe2f8c99c90@mail.gmail.com> <20080108174309.GA27187@linux-sh.org> Message-ID: <200801082318.15282.rgetz@blackfin.uclinux.org> On Tue 8 Jan 2008 12:43, Paul Mundt pondered: > On Tue, Jan 08, 2008 at 04:17:02PM +0000, Will Newton wrote: > > On Jan 8, 2008 4:06 PM, Daniel Jacobowitz wrote: > > > On Tue, Jan 08, 2008 at 03:58:00PM +0000, Will Newton wrote: > > > > Agreed, my question is whether or not adding the underscore is the > > > > correct thing to do even if your architecture prepends an > underscore > > > > to symbol names? Is there a particular reason why this was done > for > > > > Blackfin, to make a particular app work? I am trying to find out > what > > > > the correct behaviour of dlsym is, for example does it behave like > > > > this on other Unixes that have leading underscores on symbols. > > > > > > There are pretty much no Unixes that do this; a few embedded Linux > > > ports are the only exceptions I've ever encountered. > > > > I think I got the impression from the Levine "Linkers and Loaders" > > book (my copy of which seems to have vanished) that prepending an > > underscore to symbol names was common practice. Perhaps it was an > > a.out thing, that's rather before my time though... > > > It's something that a number of the -elf target do, or used to do. Most > platforms use -linux targets which don't do this, so it hasn't been a > big > deal in practice. The use of -elf toolchains for building the kernel and > things of that nature were far more prevalent in the olden days, hence > the SYMBOL_PREFIX() debacle. It's especially a very common thing on the > mmuless platforms, but likewise, this is quickly turning in to legacy > behaviour (or just a bare metal target). It's preferable to just get a > real toolchain, as anyone that remembers what the old system call tables > used to look like can attest. Most architectures have given up on > uglifying the code in order to try and accomodate these fringe > toolchains > -- and subsequently, most of the support never made it out of the 2.4 > kernels, forcing people to standardize on the -linux variants anyways. > This doesn't seem like an ureasonable direction to start pushing the > libc, either. Unless it excludes architectures - as Daniel indicated - there are complely legit reasons for doing so: > As I understand it, the only reasons are habit and to accomodate an > assembler syntax which makes symbol names ambiguous with something > else (e.g. register names). The second is the main reason why we are required to do so on Blackfin. -Robin From rgetz at blackfin.uclinux.org Tue Jan 8 20:14:18 2008 From: rgetz at blackfin.uclinux.org (Robin Getz) Date: Tue, 8 Jan 2008 23:14:18 -0500 Subject: Prepending underscores to symbol names in dlsym() (commit 20613) In-Reply-To: <200801081154.30422.vapier@gentoo.org> References: <87a5b0800801070745l5e3c4326te4627a475c342a53@mail.gmail.com> <20080108162958.GA25170@caradoc.them.org> <200801081154.30422.vapier@gentoo.org> Message-ID: <200801082314.18748.rgetz@blackfin.uclinux.org> On Tue 8 Jan 2008 11:54, Mike Frysinger pondered: > On Tuesday 08 January 2008, Daniel Jacobowitz wrote: > > On Tue, Jan 08, 2008 at 04:17:02PM +0000, Will Newton wrote: > > > On Jan 8, 2008 4:06 PM, Daniel Jacobowitz wrote: > > > > On Tue, Jan 08, 2008 at 03:58:00PM +0000, Will Newton wrote: > > > > > Agreed, my question is whether or not adding the underscore is the > > > > > correct thing to do even if your architecture prepends an underscore > > > > > to symbol names? Is there a particular reason why this was done for > > > > > Blackfin, to make a particular app work? I am trying to find out what > > > > > the correct behaviour of dlsym is, for example does it behave like > > > > > this on other Unixes that have leading underscores on symbols. > > > > > > > > There are pretty much no Unixes that do this; a few embedded Linux > > > > ports are the only exceptions I've ever encountered. > > > > > > I think I got the impression from the Levine "Linkers and Loaders" > > > book (my copy of which seems to have vanished) that prepending an > > > underscore to symbol names was common practice. Perhaps it was an > > > a.out thing, that's rather before my time though... > > > > Not on modern Unixes, anyway. Some *-elf targets do, and more *-coff > > and *-aout targets. > > > > As I understand it, the only reasons are habit and to accomodate an > > assembler syntax which makes symbol names ambiguous with something > > else (e.g. register names). If it's a habit, expect everyone to have > > the habit; if it's to accomodate the assembler, expect everyone to > > accomodate the assembler. So there shouldn't be any symbols without > > the underscore. > > the Blackfin reason was backwards compatibility with existing propriety > toolchains (and we didnt have input for those toolchains at their time of > creation). at this point, we've screwed ourselves into an ABI corner, so > there probably wont be a way to get ourselves out. unless another Blackfin > comes along that is not opcode compatible ... and we feel like shouldering > the development burden. Actually, I think that even Bernd/Jie would agree that it is not just backwards compatibility (although that was the first reason), but also with the algebraic assembly syntax (that everyone likes) Blackfin uses, it would be nearly impossible to parse things without the manditory leading underscore on symbol names. -Robin From hcegtvedt at atmel.com Tue Jan 8 22:46:49 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Wed, 09 Jan 2008 07:46:49 +0100 Subject: uClibc and expected versions of usable gcc In-Reply-To: <200801081206.47766.vapier@gentoo.org> References: <200801081206.47766.vapier@gentoo.org> Message-ID: <1199861209.10377.41.camel@localhost> On Tue, 2008-01-08 at 12:06 -0500, Mike Frysinger wrote: > any comments/thoughts/inputs/whatever ? ready set fight For the record, AVR32 architecture is only supported by GCC 4.0.x and above. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From christian.michon at gmail.com Wed Jan 9 00:06:53 2008 From: christian.michon at gmail.com (Christian MICHON) Date: Wed, 9 Jan 2008 09:06:53 +0100 Subject: uClibc and expected versions of usable gcc In-Reply-To: <200801081206.47766.vapier@gentoo.org> References: <200801081206.47766.vapier@gentoo.org> Message-ID: <46d6db660801090006p47f40e23n42d496af519863ad@mail.gmail.com> On Jan 8, 2008 6:06 PM, Mike Frysinger wrote: > at this time, i'd consider gcc-3.4.6 the oldest version worth using with > uClibc. that means it's the oldest version i'd consider adding source code > tweaks to work around gcc bugs. for older versions of gcc, if uClibc fails > to build for you due to a bug in the compiler, the answer is upgrade your > gcc, sorry. > > any comments/thoughts/inputs/whatever ? ready set fight > -mike > fine with me too, since this is the gcc's version used in DetaolB. ;-) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! From koen at dominion.kabel.utwente.nl Wed Jan 9 01:46:19 2008 From: koen at dominion.kabel.utwente.nl (Koen Kooi) Date: Wed, 09 Jan 2008 10:46:19 +0100 Subject: uClibc and expected versions of usable gcc In-Reply-To: <1199861209.10377.41.camel@localhost> References: <200801081206.47766.vapier@gentoo.org> <1199861209.10377.41.camel@localhost> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans-Christian Egtvedt schreef: | On Tue, 2008-01-08 at 12:06 -0500, Mike Frysinger wrote: | | | |> any comments/thoughts/inputs/whatever ? ready set fight | | For the record, AVR32 architecture is only supported by GCC 4.0.x and | above. With 'gcc 4.0.x' you mean 'gcc 4.0.x + atmel patch that removes blackfin support'[1], right? Koen [1] http://dominion.thruhere.net/koen/cms/fun-with-vendor-patches -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD4DBQFHhJfrMkyGM64RGpERAkYXAJi48rqdAZUO1nMLuXeDQX0IXJlnAJ4w4811 MOyCui0397RNDm5LyI53Pw== =AIjZ -----END PGP SIGNATURE----- From hcegtvedt at atmel.com Wed Jan 9 02:11:37 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Wed, 09 Jan 2008 11:11:37 +0100 Subject: uClibc and expected versions of usable gcc In-Reply-To: References: <200801081206.47766.vapier@gentoo.org> <1199861209.10377.41.camel@localhost> Message-ID: <1199873497.10377.79.camel@localhost> On Wed, 2008-01-09 at 10:46 +0100, Koen Kooi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hans-Christian Egtvedt schreef: > | On Tue, 2008-01-08 at 12:06 -0500, Mike Frysinger wrote: > | > | > | > |> any comments/thoughts/inputs/whatever ? ready set fight > | > | For the record, AVR32 architecture is only supported by GCC 4.0.x and > | above. > > With 'gcc 4.0.x' you mean 'gcc 4.0.x + atmel patch that removes blackfin > support'[1], right? > Hmm, did not know that. My guess that is from the config.sub file? Probably replaced with a config.sub which did not hold the Blackfin architecture. AFAIK no pun intended. PS! The latest GCC toolchain patches (4.2.2) includes Blackfin support ;) -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From koen at dominion.kabel.utwente.nl Wed Jan 9 02:39:09 2008 From: koen at dominion.kabel.utwente.nl (Koen Kooi) Date: Wed, 09 Jan 2008 11:39:09 +0100 Subject: uClibc and expected versions of usable gcc In-Reply-To: <1199873497.10377.79.camel@localhost> References: <200801081206.47766.vapier@gentoo.org> <1199861209.10377.41.camel@localhost> <1199873497.10377.79.camel@localhost> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans-Christian Egtvedt schreef: | On Wed, 2008-01-09 at 10:46 +0100, Koen Kooi wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Hans-Christian Egtvedt schreef: |> | On Tue, 2008-01-08 at 12:06 -0500, Mike Frysinger wrote: |> | |> | |> | |> |> any comments/thoughts/inputs/whatever ? ready set fight |> | |> | For the record, AVR32 architecture is only supported by GCC 4.0.x and |> | above. |> |> With 'gcc 4.0.x' you mean 'gcc 4.0.x + atmel patch that removes blackfin |> support'[1], right? |> | | Hmm, did not know that. My guess that is from the config.sub file? | Probably replaced with a config.sub which did not ho