Re: can't find class named `foo', as given by C++ RTTI

[Daniel Berlin <dan@cgsoftware.com>]

Daniel Berlin <dan@cgsoftware.com> writes:

> Benjamin Kosnik <bkoz@redhat.com> 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<char>', 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<char> is "numpunct<char>" (I
verified this by looking at the stabs section itself). This is, of
course, correct.
Inside the std namespace, it's named numpunct<char>.   So that's what
gcc outputs, and correctly so.  
Functions are given by mangled name,and thus, have
std::numpunct<char>, 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<char> to get
std::numpunct<char>.   

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