Re: So what is wrong with v3 C++

[Daniel Berlin <dan at cgsoftware dot com>]

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

>
> When it comes to prioritizing problems, there's some risk in a bunch
> of non-C++ programmers like me trying to assess which bugs are most
> important to fix, since we don't have daily experience showing us
> which bugs interfere with our work the most.
>
> I just talked about this on the phone with Ben Kosnik.  He says that
> the bug causing him the most trouble is the simple inability to print
> his objects.  Troubles with virtual base classes and stepping into
> virtual functions are insignificant compared to the frustration of
> being unable to see his data.
>
> Here's a simple example that illustrates the problem:
>
> $ cat scope-rtti.cc
># include <stdio.h>
>
> namespace N
> {
>   struct A
>   {
>     int x, y;
>     virtual int sum (void);
>   };
> };
>
> int
> N::A::sum ()
> {
>   return x + y;
> }
>
>
> main ()
> {
>   N::A a;
>
>   a.x = 3;
>   a.y = 4;
>   printf ("%d\n", a.sum ());
> }
> $ $Gcc3B/g++ -g scope-rtti.cc -o scope-rtti
> $ $D6/gdb/gdb scope-rtti
> GNU gdb 2001-06-28-cvs (MI_OUT)
> 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 "i686-pc-linux-gnu"...
> (gdb) break 25
> Breakpoint 1 at 0x8048813: file scope-rtti.cc, line 25.
> (gdb) run
> Starting program: /home/jimb/c++v3/play/scope-rtti
>
> Breakpoint 1, main () at scope-rtti.cc:25
> 25        printf ("%d\n", a.sum ());
> (gdb) print a
> $1 = {_vptr.A = 0x8049908, x = 3, y = 4}
>
> By default, GDB prints `a' using its compile-time type.  There's
> nothing really ABI-specific going on here, so it works okay.
>
> (gdb) set print object
> (gdb) print a
> $2 = can't find class named `N::A', as given by C++ RTTI
> (gdb)
>
> When we say `set print object', we ask GDB to print using `a''s
> run-time type.  This is really what you need for debugging, I think:
> when the compile-time type is just some base class that defines
> nothing but a bunch of virtual functions (as is the case in the bug
> report Ben just posted), the compile-time type is practically useless.
>
> Unfortunately, since GDB mishandles the scoping, this feature doesn't
> work.  If I remove the `namespace N' from the example, so the type's
> name is simply `A' instead of `N::A', everything works fine.
>
> What makes it especially urgent is that, for people working on the
> standard C++ library implementation, *every* type is in the `std'
> namespace.  So this problem will affect just about every object they
> ever want to print.  And of course, ordinary C++ code will use the
> standard library pretty frequently, too.
>
> So, if I've understood the situation correctly (all you actual C++
> users, please correct me), I think this is probably the first bug we
> should fix.
>
> I have no opinion yet on whether we would need to rewrite the dwarf 2
> reader to fix this.

It's actually a bit worse than just needing to rewrite the dwarf2 reader.

You actually can't fix the stabs reader without gcc's help and a hack.
For the stabs reader, you need to hack gcc to output fully qualified names 
for us.
This is because if you look at the stabs section, you'll see we output 
types by the normal name, instead of mangled name (types have no mangled 
name, so it would be tricky to output them :P).
So we end up with numpunct<char> or, in this case "A".

For DWARF2, we now have namespace support, and i'll see if i can get it 
into 3.0.1.  So instead of just seeing:

DW_TAG_structure_type:
	DW_AT_name: A
we now see
DW_TAG_namespace
	DW_AT_name: N
	DW_TAG_structure_type:
		DW_AT_name: A

and pull "N::A" out of this.
Yay!

However, the problem of what to do about gcc 3.0 still remains.
Also, the above doesn't help stabs, but that's an even harder issue to fix 
in general.  I'm going to assume someone hacks up gcc to output fully 
qualified names for STABS (as a general solution, as i pointed out to 
benjamin, this just don't work. But STABS has no support for namespaces 
anyway, so there's no way you could run into real trouble by doing it).

In both the stabs (for all cases), and dwarf2 (for 3.0 compiled files only, 
assuming it gets into 3.0.1), we could insert amazingly evil hacks to try 
to seperate out the namespace from the demangled names on other real 
members of the structure/type/whatever.
For DWARF2, we can easily determine what gcc version compiled the file 
(producer string), and do the ugly stuff below for 3.0 only. I don't know 
about STABS.
I.E.

Given something like:
DW_TAG_structure_type:
	DW_AT_name:  A
	DW_TAG_member:
		DW_AT_name: b
		DW_AT_MIPS_linkage_name:  _Z1N1A1b (or whatever it really is, i'm making 
this up)

When we see the structure, we look at the members, attempt to demangle some 
of their names,
and find the common prefix.
Then we add that to the front of the name.
Sick, no?

I seriously can't think of another way to do this.
We're attempting to guess at info we are missing right now.
That's a very hard thing to do.
--Dan