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

[Daniel Berlin <dan at cgsoftware dot com>]

Jim Blandy <jimb@zwingli.cygnus.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 means is that GDB wanted to find the run-time type of some object
> (probably *__fp), and failed.  Here's how GDB tries to find an
> object's run-time type:
> - GDB extracts the object's vtable.
> - it looks up the linker symbol naming the vtable (which was
>   _ZTVSt8numpunct, or something like that).
> - it demangles that name (and got "vtable for std::numpunct")
> - it pulls off the "vtable for " part
> - it tries to look up the type name (in this case, "std::numpunct") in
>   its full symbol table
>   
> In this case, GDB wasn't able to find the name std::numpunct.
> 
> Probably GDB should have been able to find std::numpunct.  But does
> the rest of the process look reasonable?  That is, was the run-time
> type of *__fp indeed `std::numpunct'?  The output from `ptype'
> suggests that its compile-time type is `class facet'.  Perhaps
> something went wrong well before we ever tried to look up the type
> name.

Oh, and just in case you were wondering why this suddenly came to a
front with the v3 abi.
1. value_rtti_type never worked well in v2.
2. in gcc 2.95.2/gcc 2.95.3, std was a hack implementation instead of
   a real namespace. 
So the name in the typeinfo would have been numpunct then.  It's now
correct, and thus, breaks gdb, as it used to when you dealt with RTTI
and real namespaces.
--Dan

-- 
"One night I walked home very late and fell asleep in somebody's
satellite dish.  My dreams showed up on TVs all over the world.
"-Steven Wright