as/ld silently creates programs with undefined references/symbols

[Daniel Jacobowitz]

On Wed, Sep 29, 2004 at 10:00:14AM +0100, 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.

This matches my experience; in the archives somewhere I attempted to
remove them from the symbol table, and completely broke the linker.

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

Should this be the default?

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

I don't think that's necessary.


-- 
Daniel Jacobowitz