Re: as/ld silently creates programs with undefinedreferences/symbols

[Richard Earnshaw <rearnsha at arm dot com>]

On Wed, 2004-09-29 at 10:00, Nick Clifton wrote:
> Hi Russell, Hi Richard,
> 
> > The Linux kernel is an example of a build system which parses the output
> > from "nm" in order to build an internal symbol table.  As I highlighted
> > before, this whole "mapping symbol" business is severly affecting the
> > usefulness of the toolchain and it is imperative that this problem is
> > fully resolved before binutils 2.16.
> 
> 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 *);
> 
> This function will determine if a given symbol symbol in a symbol table 
> is "special" in some target specific sense.  I decided that this would 
> be a safer approach, rather than adding code to make BFD produce 
> abbreviated symbol tables with the special symbols stripped.  In my 
> experience modifying symbol tables in BFD is very tricky.
> 
> I am attaching a proof of concept patch which applied to today's 
> mainline binutils sources.  It uses this new function to implement a new 
> command line switch to nm: "--skip-special" which will successfully 
> remove any of the ARM mapping symbols from its output.
> 
> Does anyone have any comments on this proposed solution ?  One thing I 
> wondered was whether bfd_is_target_special_symbol() should return a 
> string instead of a boolean.  It could return a NULL pointer for normal 
> symbols and some kind of description for special symbols.  Then the 
> caller could decide to print this description if it was displaying the 
> symbol to a user.
> 
> Cheers
>    Nick
> 
> 

Sorry for the late reply Nick.  I'm still desperately trying to catch up
after being on leave.

My fear is that with this approach it's going to mean a series of
changes at every place that walks symbol tables.  In the long run I
suspect that that will be less maintainable than trying to find a way to
separate out the two categories and present them as different entities
to those tools that need them.

R.