[Dwarf-discuss] DW_AT_MIPS_linkage_name

[Daniel Jacobowitz]

On Thu, Mar 24, 2005 at 01:13:37PM -0800, Chris Quenelle wrote:
> 
> I notice that g++ will emit the linkage name
> for declaractions of some kinds of symbols.
> (The symbols I'm looking at are all C++ symbols
> with mangled linker names.)
> 
> I'm considering the same thing for the Sun compilers
> because it makes it easier for the debugger to match
> up the declaration with other declarations and definitions
> of member functions and variables.
> 
> Has this issue been raised before?
> 
> Should we add a new attribute in the standard
> part of the attribute namespace for recording the
> linkage name of a symbol?
> 
> I think you could get by without it, if you were
> willing to merge type information in the debugger
> by doing a complete node-wise comparison of the whole
> type tree.  The debugger guy I am working with
> is resisting that idea.  :-)  It's easier to just
> compare two linker names to see if they represent
> the same C++ symbol.

I think that relying on the linkage names to do this is a horrible,
horrible, terrible idea.  I have spent a good chunk of the last three
years trying to migrate GDB away from reliance on the linkage names
(and I've got it nearly finished, too).  It causes all sorts of
problems, by offering multiple ways to identify symbols.

For instance, a lot of shortcomings in the symbolic debug information
have been overlooked because GDB's user interface used the demangled
names in type printing.  That limited what it could accept as input;
sometimes typing back exactly what GDB gives you won't work.

Can you give examples of the problems that would be solved by having
the linkage names in the debug output?  If all you want is unification
of definitions, then you can generate the un-mangled names passably
easily; comparing argument lists is a little trickier, but still not
too complex, and it can probably be avoided if you design your symbol
tables right.  I don't see why you'd want to unify declarations.

-- 
Daniel Jacobowitz
CodeSourcery, LLC