From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Daniel Berlin Cc: Benjamin Kosnik , gdb@sources.redhat.com Subject: Re: can't find class named `foo', as given by C++ RTTI Date: Wed, 27 Jun 2001 23:06:00 -0000 Message-id: <878zidi1e9.fsf@cgsoftware.com> References: <200106280455.f5S4t6T07564@fillmore.constant.com> <87hex1i3av.fsf@cgsoftware.com> X-SW-Source: 2001-06/msg00210.html Daniel Berlin writes: > Benjamin Kosnik writes: > >> This is a new class of errors that I've started seeing recently. I'm >> getting this from debugging efforts on x86/linux with current CVS >> 'src' and 'gcc' modules. For what it's worth, both --with-dwarf2 and >> default toolchains have the same error. >> >> >> (gdb) p *__fp >> can't find class named `std::numpunct', as given by C++ RTTI > This is no surprise. > Without namespace support in the symbol table, sometimes the names > aren't quite correct. And for those wondering the exact cause, it's two fold. STABS just plain out has no way of handling namespaces. And GCC tells it the name of numpunct is "numpunct" (I verified this by looking at the stabs section itself). This is, of course, correct. Inside the std namespace, it's named numpunct. So that's what gcc outputs, and correctly so. Functions are given by mangled name,and thus, have std::numpunct, but classes/types alone don't have a mangled name to give. If you had namespace support in stabs, you'd have an outer scope with a name of std, and you'd smash it together with numpunct to get std::numpunct. for DWARF2, we have a related hack, to compensate for gdb's inability to handle namespaces or smash scope names together properly. It's called DW_AT_MIPS_linkage_name. It gives a mangled name attribute. Of course, since it's a horrific hack to depend on, and not standard dwarf2, the g++ guys like Jason Merril want to see it go away. As do I. In fact, i'd be the first in line to try to shoot down any patch to add DW_AT_MIPS_linkage_name anywhere else. It increases the size of the dwarf2 info by a *lot*, and isn't necessary unless your debugger is trying to avoid having to handle stuff it should have handled years ago. We already rely on being able to get mangled names from debug info too much. This is why the clone constructors have the wrong name (they end up being fred() instead of fred::fred()). Their specification has no DW_AT_MIPS_linkage_name, because it can't. They have no DW_AT_MIPS_linkage_name beause they shouldn't need to. What really should be happening is that we should be generating qualified names on our own, and ignoring DW_AT_MIPS_linkage_name completely. This would also allow us to read symbols faster, and save memory. This is because we wouldn't have to demangle any symbol names. And we should be properly supporting namespaces, using directives, etc, anyway. It would also let us be able to support java packages properly and whatnot. I can make gcc output this info in about a day. But supporting it in gdb would take work that, as witnessed by DW_AT_MIPS_linkage_name, has been avoided for a while now. I'm not willing to do that gdb work. Sorry. I'm too busy with what I have now, and with my summer job at IBM Research. But i'll happily implement the gcc side of it if someone wants to take gdb's symbol structures and make them able to handle languages of the early nineties and beyond. Heck, i've even got a collection of references for symbol table designs that can handle these things properly and efficiently, and close enough to the existing basic symbol table structure that you wouldn't have to start anywhere near from scratch, or come up with a design on your own. > > >> >> >> ?? >> >> -benjamin > > -- > "Every so often, I like to stick my head out the window, look up, > and smile for a satellite picture. > "-Steven Wright -- "I just got out of the hospital. I was in a speed reading accident. I hit a book mark and flew across the room. "-Steven Wright