Prepending underscores to symbol names in dlsym() (commit 20613)

Mike Frysinger vapier at gentoo.org
Tue Jan 8 16:54:29 UTC 2008


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 <drow at false.org> 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://lists.busybox.net/pipermail/uclibc/attachments/20080108/602936b5/attachment-0002.pgp 


More information about the uClibc mailing list