From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Daniel Berlin Cc: gdb@sources.redhat.com Subject: Re: DWARF2 problem with g++-3.0 Date: Wed, 13 Jun 2001 07:53:00 -0000 Message-id: References: <87k82hf3n5.fsf@cgsoftware.com> X-SW-Source: 2001-06/msg00101.html Daniel Berlin 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 > (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 >