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

Paul Mundt lethal at linux-sh.org
Tue Jan 8 17:43:09 UTC 2008


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



More information about the uClibc mailing list