Re: The future of dwarf2_physname

[Jan Kratochvil <jan.kratochvil@redhat.com>]

Hi Keith,

On Fri, 20 May 2011 21:53:24 +0200, Keith Seitz wrote:
> I wouldn't say that DW_AT_MIPS_linkage_name is any more ISO C++
> compliant than anything else.

We still do not get to the agreement.  The primary source of addresses are ELF
symbols.  DW_AT_low_pc+DW_AT_high_pc are ignored in many cases.

(In other cases DW_AT_low_pc+DW_AT_high_pc is the only available address we
have but that is offtopic here.)

If you find different linkage name than DW_AT_MIPS_linkage_name then you will
not find the ELF symbol and therefore GDB will fail to find the function, as
I already reproduced on the sample code I provided.


> Just because the compiler outputs it
> does not necessarily make it sacrosanct. [gcc/33861]

DW_AT_MIPS_linkage_name is fortunately or unfortunately always right because
it is used for the ELF symbol.


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

The sky has fallen as without that patch of mine GDB failed to find the
function as I have shown before:

Message-ID: <20110516154851.GA24555@host1.jankratochvil.net>
During symbol reading, Computed physname <C::m(struct x *)> does not match demangled <C::m(x*)> (from linkage <_ZN1C1mEP1x>) - DIE at 0x3d [in module .../1].
(gdb) p c.m
pre-phyname:	   $2 = {void (C *, x *)} 0x4004f0 <C::m(x*)>
HEAD + your patch: Cannot take address of method m.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is a regression.  Until we find agreement on this point the mails do not
make sense.

And if you fix the specific `struct' physname problem I can find many other
problems as long as any "Computed physname ... does not match demangled"
message gets printed.  After you fix all of the problems you will reach the
functionality of my patch preferring DW_AT_MIPS_linkage_name and we can
continue the discussion.


> >I do not see any real regressions except incorrect testcase assumptions.
> 
> Unless the assumption is that gdb can only set breakpoints on
> linkage names,

Yes.  You do not always have DWARF for very every part of the program and all
of its libraries, you need to stay compatible with ELF .symtab naming.


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

I really do not mind which way to solve it, I would never work on GDB if
I mind anything like it.  But it must be able to print and break very every
function in at least libstdc++so.6 and something big like
/usr/lib/debug/usr/lib64/libwebkitgtk-1.0.so.debug .  There are about 10000
failed lookups on it now.


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

Yes, you can be fixing it all the following months.  Or we can use
DW_AT_linkage_name till the time you fix it.

We need to look verify your fixes against DW_AT_linkage_name anyway.


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

The problem is physname introduced some new feature - like it introduced
DMGL_RET_POSTFIX-like functionality.  If we go the standard demangling way we
regress a bit against gdb-7.2 (but not against gdb-7.1).

So I am trying to find a way to regress neither against gdb-7.1 nor against
gdb-7.2.


Thanks,
Jan