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

Robin Getz rgetz at blackfin.uclinux.org
Wed Jan 9 04:14:18 UTC 2008


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 <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.

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



More information about the uClibc mailing list