Re: The future of dwarf2_physname

[Tom Tromey <tromey at redhat dot com>]

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

I think that bug shows the opposite, actually.  If you look at the
DWARF:

 <1><25>: Abbrev Number: 2 (DW_TAG_structure_type)
    <26>   DW_AT_name        : (indirect string, offset: 0x77): Qux<((char*)(& name))>  

That is, the bug here is that G++ emits a bad and weird DW_AT_name.

But, if you look at the member function:

 <2><31>: Abbrev Number: 3 (DW_TAG_subprogram)
    <32>   DW_AT_external    : 1        
    <33>   DW_AT_name        : foo      
    <37>   DW_AT_decl_file   : 1        
    <38>   DW_AT_decl_line   : 7        
    <39>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x5a): _ZN3QuxIXadL_Z4nameEEE3fooEv       

.. run through c++filt:

    <39>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x5a): Qux<&name>::foo()  

Here, the linkage name and demangler are correct.

Also even if you strip down the class' DW_AT_name, you probably have
trouble reconstructing the template argument:

 <2><51>: Abbrev Number: 5 (DW_TAG_template_value_param)
    <52>   DW_AT_name        : V        
    <54>   DW_AT_type        : <0xaf>   
    <58>   DW_AT_location    : 6 byte block: 3 0 0 0 0 9f       (DW_OP_addr: 0; DW_OP_stack_value)

... since that is just the address of 'name', which IIUC may appear
elsewhere, perhaps without debuginfo.  I guess it ought to always appear
in minimal symbols in that case... maybe it isn't as bad as I thought.


I get this from my patch branch:

opsy. ../gdb -readnow -batch -ex 'set complaint 10000' -ex 'file /tmp/q.o'
During symbol reading...Computed physname <Qux<(char*)(&name)>::foo()> does not match demangled <Qux<&name>::foo()> (from linkage <_ZN3QuxIXadL_Z4nameEEE3fooEv>) - DIE at 0x31 [in module /tmp/q.o]...

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

Keith> I agree.

Great, we have a starting point :)

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

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

Yes, I actually agree with both of you, in the sense that I think both
sets of tests ought to pass.

Tom