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

Robin Getz rgetz at
Wed Jan 9 04:18:15 UTC 2008

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


More information about the uClibc mailing list