DWARF2 problem with g++-3.0

Jim Blandy jimb@zwingli.cygnus.com
Wed Jun 13 07:53:00 GMT 2001


Daniel Berlin <dan@cgsoftware.com> writes:
> 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.

I know that there are a bunch of problems with GDB and the GCC V3 C++
ABI.  I don't understand what they are yet, so this is definitely
helpful.

Rewriting the dwarf2 reader is a big change.  I'd need to understand
the current reader's problems more thoroughly than I do now before I
could approve a rewrite.  Modulo the sarcasm, thanks for taking the
time to explain these problems.


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



More information about the Gdb mailing list