Re: [RFA] dwarf2_physname

[Keith Seitz <keiths at redhat dot com>]

On 09/01/2009 04:42 PM, Daniel Jacobowitz wrote:
> OK.  That'd be a big improvement over the last state of my tree; in
> order to call a memeber function, we had to match the ELF symbol
> exactly or GDB would bogusly report it as "inlined".

A lot has changed since the patch you sent me. I'd be surprised if you 
even recognized your patch inside mine. :-)

> If uniqueness is all that's required, maybe there's some less
> expensive representation than a string encoding of the arguments?

That makes searching for a symbol a lot more difficult and slower. The 
point of this is to reduce all classes/templates/methods/etc names to 
their most basic source code representations to make searching easier 
and more reliable. The sad fact of the matter is, linkage_names are NOT 
reliable.

> I'm happy to test with RealView.  I might be able to test with ICC
> also, but I haven't tried that in forever.  I believe it's freely
> available.

I've spent the last 1.5 weeks investigating proprietary compilers, and I 
can only assume that no one seriously ever runs gdb's test suite on 
either RealView or ICC. CVS HEAD shows almost 1,000 test failures on 
each compiler.

I could not even get dejagnu to cope with non-gcc compilers without 
resorting to writing wrappers around ICC and RealView to translate gcc 
command-line options into something appropriate for those other 
proprietary compilers.

But here's what I've discovered.

ARM RealView: My expr-cumulative branch introduces three regression 
failures -- two of them in C++ tests. However, it also allows RealView 
to pass over two hundred previously failing or erroring C++ tests. I can 
provide diffs. On my "realcpp" test, RealView fails almost all of the 
template tests. This is because RealView relies on DW_AT_template_* 
attributes which gdb does not yet know about. [This will likely be my 
next task.]

ICC: This compiler really relies on DW_AT_MIPS_linkage_name because its 
DWARF output is *seriously* messed up. As expected on expr-cumulative, 
ICC fails approximately 60 additional C++ tests. The main problem is not 
that it doesn't really pass the test, but because of ICC's foobar'd 
DWARF output, the user has to do things a little differently, e.g., 
"break foo::foo" doesn't work, but "break foo::foo()" does.

As I mentioned, this is because ICC plays fast and loose with the DWARF 
standard. Take, for example, the simple case of a constructor, 
foo::foo(void), ICC will output (this is the first DIE after the comp 
unit DIE):

 <1><e0>: Abbrev Number: 3 (DW_TAG_subprogram)
    <e1>   DW_AT_decl_line   : 4
    <e2>   DW_AT_decl_column : 3
    <e3>   DW_AT_decl_file   : 1
    <e4>   DW_AT_specification: <0x11a>
    <e8>   DW_AT_name        : foo
    <ec>   DW_AT_MIPS_linkage_name: _ZN3fooC1Ev
    <f8>   DW_AT_low_pc      : 0x8048434
    <fc>   DW_AT_high_pc     : 0x804843a
    <100>   DW_AT_external    : 1
 <2><101>: Abbrev Number: 4 (DW_TAG_formal_parameter)
    <102>   DW_AT_type        : <0x147>
    <106>   DW_AT_artificial  : 1
    <107>   DW_AT_name        : this
    <10c>   DW_AT_location    : 2 byte block: 75 8      (DW_OP_breg5: 8)

So far so good. However, if you look at the actual definition of the 
class foo (<11a>, the specification listed in the DIE above):

 <1><110>: Abbrev Number: 5 (DW_TAG_class_type)
    <111>   DW_AT_decl_line   : 1
    <112>   DW_AT_decl_column : 7
    <113>   DW_AT_decl_file   : 1
    <114>   DW_AT_accessibility: 1      (public)
    <115>   DW_AT_byte_size   : 1
    <116>   DW_AT_name        : foo
 <2><11a>: Abbrev Number: 6 (DW_TAG_subprogram)
    <11b>   DW_AT_decl_line   : 4
    <11c>   DW_AT_decl_column : 3
    <11d>   DW_AT_decl_file   : 1
    <11e>   DW_AT_accessibility: 1      (public)
    <11f>   DW_AT_type        : <0x13f>
    <123>   DW_AT_prototyped  : 1
    <124>   DW_AT_name        : foo
    <128>   DW_AT_MIPS_linkage_name: _ZN3fooC1Ev
 <3><134>: Abbrev Number: 7 (DW_TAG_formal_parameter)
    <135>   DW_AT_type        : <0x147>
    <139>   DW_AT_name        : $01

Here you can see that DIE <134> is NOT marked artificial. Additionally, 
its DW_AT_name conflicts with the one previously listed, which I think 
is playing pretty loose with the standard (and certainly makes life 
difficult for the debugger). I did not even bother with my realcpp tests 
on this compiler.

> > I know that "f<(char*)(&Foo)>" is ugly, but that is the name that gcc
> > gives us (DW_AT_name for this DIE), so we have to use it. [I am
> > assuming we could get this cleaned up/"fixed" in gcc.]

> We could, as long as we do something not horribly nonsensical with the
> names there now - which are a bit random.

Dodji is already working on this and a bunch of other DWARF 
cleanups/additions, especially in the area of template debug info. 
AFAICT his interpretation of the DWARF spec reads more like mine (and 
ARM's) than Intel's. O:-)

Is there anything else you want me to investigate? [PLEASE don't say 
another proprietary compiler!!]

Keith