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

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

[Benjamin Kosnik]

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
(gdb) ptype __fp
type = class facet {
  private:
    size_t _M_references;

  protected:
    facet(unsigned);
    facet(unsigned);
    ~facet();
    virtual ~facet();
    virtual ~facet();
    static 
    void <badly mangled name '_S_create_c_locale__5facet_ZNSt6locale5facet18_S_create_c_localeERP15__locale_structPKc'>;
    static 
    void <badly mangled name '_S_destroy_c_locale__5facet_ZNSt6locale5facet19_S_destroy_c_localeERP15__locale_struct'>;
  private:
    void _M_add_reference();
    void _M_remove_reference();
    facet(std::locale::facet const&);
    facet(std::locale::facet const&);
    void operator=(std::locale::facet const&);
}

Of course, the 'badly mangled name' bits are a bit disconcerting as well.

This is from libstdc++-v3/testsuite/22_locale/members.cc, line 73

I step into this function:
  locale		loc_fr("fr_FR");

As so:

(gdb) where
#0  std::locale::_Impl::_M_install_facet(std::locale::id const*, std::locale::facet*) (this=0x810a488, __idp=0x8107b20, __fp=0x810a5e0)
    at /mnt/hd/bliss/src.gcc/libstdc++-v3/src/localename.cc:196
#1  0x080b37b8 in void std::locale::_Impl::_M_init_facet<std::numpunct<char> >(std::numpunct<char>*) (this=0x810a488, __facet=0x810a5e0)
    at /mnt/hd/bliss/src.gcc/libstdc++-v3/include/bits/localefwd.h:365
#2  0x0809b994 in std::locale::_Impl::_Impl(std::string, unsigned) (
    this=0x810a488, __str=0xbffff680, __refs=1)
    at /mnt/hd/bliss/src.gcc/libstdc++-v3/src/localename.cc:103
#3  0x08096ea9 in std::locale::locale(char const*) (this=0xbffff870, 
    __s=0x80d5c4c "fr_FR")
    at /mnt/hd/bliss/src.gcc/libstdc++-v3/src/locale.cc:376
#4  0x0804888c in test02() () at 22_locale/members.cc:73
#5  0x080492bc in main () at 22_locale/members.cc:136
#6  0x0804d412 in __libc_start_main (main=0x80492ac <main>, argc=1, 
    ubp_av=0xbffff964, init=0x80480b4 <_init>, fini=0x80d5c20 <_fini>, 
    rtld_fini=0, stack_end=0xbffff95c) at ../sysdeps/generic/libc-start.c:129


??

-benjamin

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

[Daniel Berlin]

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. 
5 to 1 says ptype 'numpunct<char>' works.

It's good to not have to worry about this stuff anymore.

I think i'll go implement dwarf2.1 namespace support in gcc.
That way, I can at least say "Well, we output the info, but gdb can't
use it".


> 
> 
> ??
> 
> -benjamin

-- 
"Every so often, I like to stick my head out the window, look up,
and smile for a satellite picture.
"-Steven Wright

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

[Benjamin Kosnik]

> > (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. 
> 5 to 1 says ptype 'numpunct<char>' works.

Yeah but doesn't really help me in terms of a debugging strategy.

:(

What about the demangling bits in the ptype output? Are those expected too?

Is special namespace support really necessary? I mean, the namespace 
qualified symbol *is* the correct name. Omitting the namespace is a bug.

> It's good to not have to worry about this stuff anymore. 
> I think i'll go implement dwarf2.1 namespace support in gcc.
> That way, I can at least say "Well, we output the info, but gdb can't
> use it".

Kind of depressing, but oh well. Any other takers?

-benjamin

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

[Daniel Berlin]

Benjamin Kosnik <bkoz@redhat.com> writes:

>> > (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. 
>> 5 to 1 says ptype 'numpunct<char>' works.
> 
> Yeah but doesn't really help me in terms of a debugging strategy.
> 
>:(
> 
> What about the demangling bits in the ptype output? Are those
> expected too?
Dunno offhand.
Does that occur with both dwarf2 and stabs?

> 
> Is special namespace support really necessary?
Special?
You mean special as in "any whatsoever"?
Yes.
You have a namespace, and if you want all the symbols inside it named
correctly, you need to support namespaces.
At least you need to have them, and their names, and stop relying on
mangled name hacks to get fully qualified names.

>  I mean, the namespace 
> qualified symbol *is* the correct name.
Correct in what way?
>  Omitting the namespace is a
> bug.
No it's not, it's perfectly correct given that
1. STABS has no way to represent namespaces. Thus, they are ignored.
2. GCC doesn't output the namespace die named std of which those would
   be children.

The dwarf2 standard doesn't say the names given are to be fully
qualified. In fact, just the opposite is the general practice. If you
want fully qualified names, you are expected to generate them, which
isn't all that tricky to do.
The only reason the others have the std:: in front of them is because
of the mangled name hack.

In fact, it would be bad to give fully qualified names there.

Think of what happens if you have:

DW_TAG_namespace:
        DW_AT_name "std"
        DW_TAG_class:
                DW_AT_name "std::numpunct<char>"
...
DW_TAG_namespace:
        DW_AT_name "danspace"
        DW_TAG_using:
                DW_AT_name "std"

Now, if we don't change the symbol structures, and do this by copying
all the symbols in std to the block for danspace, gdb will print out, and
treat, the names as if they were "danspace::std::numpunct<char>".

It's only the symbol readers that do it wrong, AFAIK. The rest of GDB
understands enough about scoping to handle namespaces through copying
symbols to the right place if we really wanted to.

And if you start going down the path of "Oh, well, i'll just remove
the name we have in the using from the name in the namespace symbols
the using is referring to", realize it would only work for two
namespaces max, would get very confusing if you did "using namespace
dan=fred", etc.

This is why we need to generate the qualified names ourselves.

The non-hack solution here is to add namespace support to gcc's dwarf2
output, and gdb's dwarf2 reader.

At a minimum, you could get away with smashing together the names of
the scopes in which a given die appears, if those scopes have names,
seperated by the scope qualifier of "::", and using that as your name.
This would at least be better than what we do now, which is rely on
a non-standard extension to give us mangled names to get qualified
names from, which isn't the right thing to be doing, is slow,
non-standard, and  wastes memory to boot. 

The only thing what we have now has going for it is that it kinda
almost used to work for g++ < 3.0.




> 
>> It's good to not have to worry about this stuff anymore. 
>> I think i'll go implement dwarf2.1 namespace support in gcc.
>> That way, I can at least say "Well, we output the info, but gdb can't
>> use it".
> 
> Kind of depressing, but oh well. Any other takers?

> 
> -benjamin

-- 
"One day I got on the usual bus, and when I stepped in, I saw the
most gorgeous blond Chinese girl...  I sat beside her.  I said,
"Hi," and she said, "Hi," and then I said, "Nice day, isn't
it?," and she said, "I saw my analyst today and he says I have a
problem."  So I asked, "What's the problem?"  She replied, "I
can't tell you.  I don't even know you..."  I said, "Well
sometimes it's good to tell your problems to a perfect stranger
on a bus."  So she said, "Well, my analyst said I'm a
nymphomaniac and I only like Jewish cowboys...  By the way, my
name is Denise."  I said, "Hello, Denise.  My name is Bucky
Goldstein..."
"-Steven Wright

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

[Benjamin Kosnik]

> Does that occur with both dwarf2 and stabs?

Yes.

> > Is special namespace support really necessary?
> Special?
> You mean special as in "any whatsoever"?
> Yes.

Aaaaaaaaah. 

> The dwarf2 standard doesn't say the names given are to be fully
> qualified. In fact, just the opposite is the general practice. If you
> want fully qualified names, you are expected to generate them, which
> isn't all that tricky to do.

Ok.

> Think of what happens if you have:
> 
> DW_TAG_namespace:
>         DW_AT_name "std"
>         DW_TAG_class:
>                 DW_AT_name "std::numpunct<char>"
> ...
> DW_TAG_namespace:
>         DW_AT_name "danspace"
>         DW_TAG_using:
>                 DW_AT_name "std"
> 
> Now, if we don't change the symbol structures, and do this by copying
> all the symbols in std to the block for danspace, gdb will print out, and
> treat, the names as if they were "danspace::std::numpunct<char>".
> 
> This is why we need to generate the qualified names ourselves.
> 
> The non-hack solution here is to add namespace support to gcc's dwarf2
> output, and gdb's dwarf2 reader.

Ok. Thanks. I wasn't thinking about types, and aliasing namespaces. It's 
encouraging to see the support for scoping in other parts of gdb, 
although symbol support seems lacking.

-benjamin

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

[Daniel Berlin]

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

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

[Benjamin Kosnik]

> 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.

Ah. I get it now. So this namespace issue is probably the same problem that 
nested types are having...

I was wondering about the ctor issue.

> 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.

These are all required features in gdb, not optional features, right?

> I can make gcc output this info in about a day.

Well then.

> i've 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.

Might as well post the links or citations if you've got them handy.

-benjamin

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

[Daniel Berlin]

Benjamin Kosnik <bkoz@redhat.com> writes:

>> 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.
> 
> Ah. I get it now. So this namespace issue is probably the same problem that 
> nested types are having...
Yes.
Exactly.

It usually clicks once you realize that all those things named
"std::a::b::c::d" are really all in the same scope (not the global
scope, IIRC, I mean the ones appearing in each file are in that file's
file-level scope), and not in the scope named std::a::b::c.
I.E. It's all an illusion.
There is no spoon.

Nested classes and structs *might* have the right scope, it depends on
the sym reader.


> 
> I was wondering about the ctor issue.
> 
>> 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.
> 
> These are all required features in gdb, not optional features,
> right?

Well, we could start by stop trying to put up the illusion 
> 
>> I can make gcc output this info in about a day.
> 
> Well then.
Patch submitted a little earlier to add support for at least
outputting namespaces (no importing the declarations into other
scopes).

This will give us the ability to make up the qualified names on our
own, at least.
> 
>> i've 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.
> 
> Might as well post the links or citations if you've got them handy.
Let me hunt it down, it's somewhere on my FS.

> 
> -benjamin

-- 
"I have a friend named Dennis.  Both of his parents were midgets,
but he isn't a midget.  He's a midget-dwarf.  He's two inches
tall.  He's the one who poses for trophies.
"-Steven Wright

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

[Benjamin Kosnik]

> >> I can make gcc output this info in about a day.
> > 
> > Well then.
> Patch submitted a little earlier to add support for at least
> outputting namespaces (no importing the declarations into other
> scopes).

Ha! You did. Pretty funny. Well done.

> Let me hunt it down, it's somewhere on my FS.

Cool. 

Thanks,
benjamin

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

[Jim Blandy]

Daniel Berlin <dan@cgsoftware.com> writes:
> I'm too busy with what I have now, and with my summer job at IBM
> Research.

Congrats!

> 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.

Could you post those references?

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

[Daniel Berlin]

--On Friday, June 29, 2001 5:15 PM -0500 Jim Blandy 
<jimb@zwingli.cygnus.com> wrote:

>
> Daniel Berlin <dan@cgsoftware.com> writes:
>> I'm too busy with what I have now, and with my summer job at IBM
>> Research.
>
> Congrats!
>
>> 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.
>
> Could you post those references?
I'm still trying to find which computer I put them on.
However, one immediately comes to mind, since the book is sitting next to 
me.
But first, realize that to implement in GDB, you must do one of two things.
1. Change GDB to only explicitly keep track of the current scope (IE like 
the compilers do), and magically have the symbols for that scope.  This 
would require so much redesign it's not even funny.
2. Convert what the designs say from stacks to blockvectors (IE most are 
based on stacks where you only keep the current visible scopes around.  We 
need all the scopes, so you just have to think of how to do the conversion 
between the two in your head. It's usually not that difficult to do at all.)

I'd suggest, for obvious reasons, 2.

But anyway, here's the one reference I have sitting next to me, while i 
hunt the rest:

Section 3 of Advanced Compiler Design and Implementation - Steven Muchnick

It's titled "Symbol table structure".

He explicitly covers how to handle open and closed scope languages, and 
uses blocks like we do (Except the actual symbols aren't in the blocks, the 
blocks have a pointer into a large table of symbols, which is also hashed. 
Much like the minsyms are linked to each other, and placed into the minsym 
hash table).

This is probably the easiest one to implement anyway, and has pseudocode 
and pictures. :)

I should have the other references by the end of the weekend.
--Dan

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

[Jim Blandy]

Daniel Berlin <dan@cgsoftware.com> writes:
> But first, realize that to implement in GDB, you must do one of two things.
> 1. Change GDB to only explicitly keep track of the current scope (IE like 
> the compilers do), and magically have the symbols for that scope.  This 
> would require so much redesign it's not even funny.
> 2. Convert what the designs say from stacks to blockvectors (IE most are 
> based on stacks where you only keep the current visible scopes around.  We 
> need all the scopes, so you just have to think of how to do the conversion 
> between the two in your head. It's usually not that difficult to do at all.)
> 
> I'd suggest, for obvious reasons, 2.

Yeah, I'd say 1. doesn't apply to us. 

> Section 3 of Advanced Compiler Design and Implementation - Steven Muchnick
> 
> It's titled "Symbol table structure".

Oh, I've got that, actually.

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

[Jim Blandy]

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.

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

[Daniel Berlin]

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.

Nope. The name of the type in the symbol table is numpunct<char>,
because of scoping problems.


-- 
"A friend of mine once sent me a post card with a picture of the
entire planet Earth taken from space.  On the back it said,
"Wish you were here."
"-Steven Wright

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

[Benjamin Kosnik]

> > In this case, GDB wasn't able to find the name std::numpunct.

Right.

> > Probably GDB should have been able to find std::numpunct.  

Definitely, GDB should be 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.
> 
> Nope. The name of the type in the symbol table is numpunct<char>,
> because of scoping problems.

Right. The ptype output is the base class, not what I really want to see. 
I'd like to be able to look at the contents of the object, for instance. 
I think this is a reasonable request.

You might want to look at this:
http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-doxygen-3.0/class_std__numpunct.html

There's been some discussion on this thread: I'll give you a bit of time 
to catch up.

-benjamin

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

[Daniel Berlin]

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