Re: The future of dwarf2_physname

[Daniel Jacobowitz <drow@false.org>]

On Wed, May 18, 2011 at 03:34:43PM -0700, Keith Seitz wrote:
> In short, if gdb uses DW_AT[_MIPS]_linkage_name when available, we
> can bypass constructing the physname *and* canonicalization, so gdb
> would only have to do this when DW_AT[_MIPS]_linkage_name is missing.
> Today this only happens AFAIK with gcc and ctors. I don't know about
> other compilers.

For all intents and purposes, no other current compiler emits
DW_AT_MIPS_linkage_name.

> This could be a sizable performance win (not yet tested or
> quantified). While it does introduce some regressions, many are
> compiler problems and some are template problems (the linkage name
> contains the return type, and 1) gdb isn't equipped to deal with
> that; 2) it makes for a horrible user experience having to specify it
> all the time). There might be others, I have only delved into this a
> bit myself today.
> 
> So the first question to be asked here is, Should we adopt Jan's
> patch, or some variation of it, to use DW_AT_linkage_name when
> available?

I've spent a lot of time on this question.  It's similar to the
approach I took in my previous implementation, but I was never happy
with it.  You get bizarre differences in behavior between compilers
(although the same thing does admittedly happen just based on the
DWARF output).

GCC ideally ought to get away from outputting linkage names; it's a
big space cost in the debug information.  That offers a potential
tie-breaker between the two strategies; keep using the linkage names
for old versions of GCC, and transition away as GCC improves.

In general, the sort of cross-check Jan has implemented could never
reliably pass without extensions to DWARF.  Once you get up into
templates, especially, there are template arguments that are hard
or impossible to represent in template parameter DIEs.

-- 
Daniel Jacobowitz