Re: The future of dwarf2_physname

[Keith Seitz <keiths@redhat.com>]

Hi, Jan,

On 05/19/2011 12:23 PM, Jan Kratochvil wrote:
> If the linkage name is wrong for whatever reason this is an ABI issue for GCC,
> it is out of scope of GDB.  Linkage name is defined by the ISO C++ standard,
> neither GCC nor GDB can change it.  If GCC is not ISO C++ compliant then GCC
> should be fixed (and possibly deal with the ABI breakage) but such ISO C++
> compliance issue is out of scope of GDB.

We work around GCC ABI issues all the time GDB. dwarf2read.cc is riddled 
with workarounds for various flavors of GCC.

> Trying to introduce new "better" naming for C++ methods which is in 90% the
> same as GCC's and ISO C++'s idea seems a bit messy for me.

If you mean "better" as in "more reliable", then I'm afraid that *was* 
the point. I don't like it, either, TBH, because there's a bunch of 
overhead involved. But it seemed like a reasonable thing to do at the 
time, and it still does, especially if you take GCC out of the discussion.

I wouldn't say that DW_AT_MIPS_linkage_name is any more ISO C++ 
compliant than anything else. Just because the compiler outputs it does 
not necessarily make it sacrosanct. [gcc/33861]

> That is the GCC and ISO C++ naming should be always available in GDB.  I am
> not against allowing also other aliases for the same symbol.  The availability
> of symbol aliases is discussed more at the end of this mail.

I agree.

> This is a regression.  And it will always be a regression for any
> physname != DW_AT_linkage_name as with my cross-check patch it prints:
> Computed physname<std::ios_base::unsetf(enum std::_Ios_Fmtflags)>  does not match demangled<std::ios_base::unsetf(std::_Ios_Fmtflags)>  (from linkage<_ZNSt8ios_base6unsetfESt13_Ios_Fmtflags>)

That's simply a bug. They get found, they get fixed. The sky is not falling.

> I do not see any real regressions except incorrect testcase assumptions.

Unless the assumption is that gdb can only set breakpoints on linkage 
names, I don't call the test cases broken or illegal. If your argument 
is that you don't like the way it was solved, that's an entirely 
different assertion, and one with much more merit.

> $ nm -C gdb.cp/cp-relocate.o
> 0000000000000000 W int func<1>(int)
> print func<1>(int)
> No symbol "func<1>" in current context.
> (gdb) FAIL: gdb.cp/cp-relocate.exp: get address of func<1>(int)
>
> but:
> (gdb) print 'int func<1>(int)'
> $1 = {int (int)} 0x28<func<1>(int)>
>
> This is a regression against gdb-7.2 (physname) but in pre-physname it also
> did not work.  The symbols canonicalization in decode_variable could also
> strip the leading return types.

Another bug slipped in. It, too, can be fixed. [That looks like a 
psymtab-related bug, btw.]

But as I keep saying, I am not a maintainer. This is a decision for 
maintainers. I was simply asking how maintainers wanted me to proceed.

Two maintainers believe that making the switch now is the best approach. 
As far as I am concerned, the matter is closed.

Keith