This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: The future of dwarf2_physname
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