Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tue, Jan 08, 2008 at 09:54:22AM +, Will Newton wrote: On Jan 7, 2008 4:30 PM, Carmelo AMOROSO [EMAIL PROTECTED] 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.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Jan 8, 2008 10:14 AM, Paul Mundt [EMAIL PROTECTED] 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=20613r1=20612r2=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. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tuesday 08 January 2008, Will Newton wrote: On Jan 8, 2008 10:14 AM, Paul Mundt [EMAIL PROTECTED] 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=20613r1=20612r2=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__ add _ #else do not add _ #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 signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tue, Jan 08, 2008 at 03:58:00PM +, 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 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Jan 8, 2008 3:44 PM, Mike Frysinger [EMAIL PROTECTED] wrote: http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/ldso/libdl/lib dl.c?rev=20613r1=20612r2=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__ add _ #else do not add _ #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. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tuesday 08 January 2008, Will Newton wrote: On Jan 8, 2008 4:06 PM, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Tue, Jan 08, 2008 at 03:58:00PM +, 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 signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tuesday 08 January 2008, Daniel Jacobowitz wrote: On Tue, Jan 08, 2008 at 04:17:02PM +, Will Newton wrote: On Jan 8, 2008 4:06 PM, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Tue, Jan 08, 2008 at 03:58:00PM +, 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 signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tue, Jan 08, 2008 at 04:17:02PM +, Will Newton wrote: On Jan 8, 2008 4:06 PM, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Tue, Jan 08, 2008 at 03:58:00PM +, 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 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
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 signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
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 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: uClibc and expected versions of usable gcc
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 signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
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 [EMAIL PROTECTED] 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 signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: uClibc and expected versions of usable gcc
On Tue, 2008-01-08 at 12:06 -0500, Mike Frysinger wrote: cut limit GCC support to 3.4.6 or greater 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 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
