From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: jimb@redhat.com Cc: gdb@sources.redhat.com Subject: DWARF2 problem with g++-3.0 Date: Tue, 12 Jun 2001 20:41:00 -0000 Message-id: <87k82hf3n5.fsf@cgsoftware.com> X-SW-Source: 2001-06/msg00096.html 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 (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