DWARF2 problem with g++-3.0

[Daniel Berlin <dan at cgsoftware dot com>]

Jim, since your the maintainer, i'm sure you already know this, but
because of dwarf2read's inability to handle a lot of dwarf2 properly currently,
it doesn't work all that well with g++-3.0.

Compile misc.cc, from the gdb.c++ testsuite, with dwarf-2 info on,
using gcc-3.0.

(%:/buildspace/dwarf2gdbtree/src/gdb/testsuite/gdb.c++)- nonworkinggdb ./a.out
GNU gdb 2001-06-12-cvs
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-unknown-linux-gnu"...
(gdb) p vB
$1 = {void (void **)} 0x100013ac <vB>
(gdb) ptype vB
type = void (void **)
(gdb)

This is completely wrong, it's assigned the name vB to the constructor
instead of vB::vB.
and ptype vB, which is the name of the class, gives you the type of
the constructor instead.
Bad.

It should be doing this:

(%:/buildspace/dwarf2gdbtree/src/gdb/testsuite/gdb.c++)- ../../gdb ./a.out
GNU gdb 2001-06-12-cvs
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-unknown-linux-gnu"...
 
(gdb) ptype vB
type = class vB : public virtual vA {
  public:
    int vb;
    int vx;
 
    vB & operator=(vB const&);
    vB(int, const void **, class vB &);
    vB(int, const void **);
}
(gdb) p vB
Attempt to use type name as an expression

The problem, as i'm sure you know, is that we go to lookup the
specification die for the clone constructor (which is an abstract entity at
the subprogram level, not a class member. Which is correct), and take
an attribute from it. In this case, the attribute is the name.
However, this won't work for names, because the name on the
specification die, which is a class member, isn't a fully qualified
name.  It can't be fully qualified, because it doesn't really
exist. It's a specification for the two out-of-class constructors that
are the real constructors.
So, since we fail to notice that the specification, it's really inside
another scope, and thus, we end up naming it "vB", instead of
"vB::vB".  The real constructors have no DW_AT_mips_linkage attribute,
because DW_AT_mips_linkage is a hack, not necessary, and we're trying
to make it go away anyway. 

I'd help out here, and provide a patch that rewrites much of the
dwarf2 reader because of this and other problems, but i can't make
patches that work, and i'm sure, since you are the dwarf2 maintainer
after all, you took care of this problem, and have a patch ready for
it.  And i'm sure it won't be a bad hack, like tracking the nesting
level of each die in an array, ignoring partial symbols that have a
specification in a deeper nesting level, and then getting the real
name for the other constructor dies (that have an abstract origin,
instead of a specification, but suffer the same fate anyway), from the
pubnames table.  Cause that would be a pretty horrific hack, and
depend on the behavior of g++ outputting fully qualified pubnames (Not
that the dwarf2 reader works all that well with other compilers, due
to it's failure to support ref_addr properly, something else i fixed,
but am sure you have patches just around the corner for).  Nor would I
think you would attempt to perform the hack of adding a prefix
argument to the read_partial_die, so we can try to pass along the
current scope's prefix, which wouldn't work anyway (you'd need to
store it in the partial die info).  Nope. I'm sure you've already
solved this problem the right way, no?

I guess I'll submit the rewrite anyway, even though i know it's not
necessary, since as I said, i've got faith you've got this problem
under control already.

It is, after all, a pretty important bug, since it's nasty in the way
it affects people, being that once things get into the symbol table
(IE the psymtab gets converted) the lookups work since they find the
real symbol first.  Of course, this means you won't really notice it
until you have programs consisting of more than one file, or shared
libraries, where just running the program doesn't cause the psymtab to
be converted because that's where the symbol named "main" is.  

Cause then you just get funny behavior like:
(gdb) info func vB
All functions matching regular expression "vB":
 
File misc.cc:
void vB(void **);
void vB(vB *, void **);
(gdb) b vB
"vB" is not a function
(gdb)
Which, as your quote today said, is "Amazingly silly".
Notice we haven't actually fixed the problem here, just papered over
it and gotten lucky.

Normally, whether vB is a type or not will depend on whether you've
looked up symbols in the file it's in or not.  The kind of context
dependent bug that you really don't want to have.

Then there's another issue of the dwarf2 reader saying "if
(die->has_children && ! die_is_declaration (die))
{
...
}
else
{
        /* No children */
}
"
which is obviously wrong (it may have children, and be a declaration,
as die_is_declaration defines it, because die_is_declaration isn't
quite right), and exposed by libstdc++-v3, resulting in stubs we
shouldn't have.  The fix, is of course, to remove die_is_declaration
entirely there.
Non-defining declarations have no children. What would they be? If we
have one that does, we should do *something with it*, not just ignore
it entirely.
This also makes the comment right. You knew all of this of course, so
i don't know why i'm telling you.
In fact, i'm sure you know all about the rest of the issues, and have
them taken care of on the dwarf2 side of things.  So i'm only really
submitting the rewrite for giggles.  Not that my code is worth much more.

Since the GCC 3.0 release is in 4 days, I expect you'll submit your
code soon.

HTH,
Dan


-- 
"I got up one morning and couldn't find my socks, so I called
Information.  She said, "Hello, Information."  I said, "I can't
find my socks."  She said, "They're behind the couch."  And they
were!
"-Steven Wright