This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: as/ld silently creates programs with undefined references/symbols
- From: Russell King <rmk at arm dot linux dot org dot uk>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: binutils at sources dot redhat dot com, Richard Earnshaw <rearnsha at arm dot com>
- Date: Fri, 8 Oct 2004 16:15:13 +0100
- Subject: Re: as/ld silently creates programs with undefined references/symbols
- References: <40F243E2.2070506@redhat.com> <1089620642.8278.68.camel@pc960.cambridge.arm.com> <20040712092625.A2623@flint.arm.linux.org.uk> <1089621632.8278.72.camel@pc960.cambridge.arm.com> <20040808165653.B17968@flint.arm.linux.org.uk> <411CF9DA.5090202@redhat.com> <4121BE71.6060508@redhat.com> <20040923104005.A18950@flint.arm.linux.org.uk> <415A799E.2030706@redhat.com> <4166AB51.7070402@redhat.com>
On Fri, Oct 08, 2004 at 03:59:29PM +0100, Nick Clifton wrote:
> Hi Russel,
>
> > I have a prototype solution to this problem, but I would like more input
> > from anyone who is interested. My idea is to provide a new function in
> > the BFD ABI:
> >
> > bfd_boolean bfd_is_target_special_symbol (bfd *, asymbol *);
>
> I had noone complain about this approach so I have decided to go ahead
> and check it in. I have increased the BFD version number to reflect the
> presence of a new function in the API, and I have added a new switch to
> nm and objdump called "--special-syms". By default these tools will now
> skip displaying the ARM Mapping symbols unless this new switch is used.
Nick,
As you'll see from this thread on linux-kernel:
http://lkml.org/lkml/2004/9/27/181
the problem that these mapping symbols cause is fairly widespread
across multiple programs. Just fixing binutils isn't going to
resolve the problem - so I'm not entirely convinced that fixing
the nm and objdump output will resolve all problems.
I think the whole idea of mapping symbols needs a serious rethink,
and any other such changes to the ARM ELF format needs _careful_
consideration both from people actively involved with the toolchain
as well as operating system people.
--
Russell King