Re: So what is wrong with v3 C++

Re: So what is wrong with v3 C++

[Michael Elizabeth Chastain]

> >   gdb/7   cout << 1 doesn't work for c++
> This one is bogus.
> It does work.
> I poitned this out on gdb.bugs.

No.  You pointed out that it works with dwarf2.  You acknowledged
that it doesn't work with stabs.  You wrote:

  http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=23&database=gdb

  As did I, look for the posting where i showed it worked for me with
  dwarf2 on both ppc, and x86.

  It doesn't work on stabs for one of two reasons:
  ....

> >   gdb/40  C++ template functions have return types in their names
> Normal. They should.
> Look at the ABI standard.

The problem is that a template function has a name such as
"int add_two_values<int>(int, int)", whereas a normal function has a
name such as "add_two_values(int, int)".  Note the return type at the
beginning of the name.

Specifically:

  % c++filt
  _Z14add_two_valuesIiET_S0_S0_
  int add_two_values<int>(int, int)
  _Z14add_two_valuesii
  add_two_values(int, int)

This was also a problem with v2.

I'm looking at section 5.1.2 of the ABI standard, "General Structure".
The demangling grammar gets down to "unqualified source code identifier"
in about ten productions, with no reference to the function return type.
Can you quote me the part of the ABI standard that puts the return type
before the name?

> >   gdb/41  testsuite/gdb.c++/demangle.exp needs v3 coverage
> libiberty already has demangler coverage for the demangler, why do we
> need it in gdb as well?

Gdb is the #1 client of the demangler so it's in our interest to check
for demangling bugs in our test suite.  That way we can find them and
push them upstream more easily.

The second reason is that libiberty/testsuite/demangle-expected has
only five cases that start with "_Z", and they are all --format=java.
So we actually have very little v3 coverage right now.

BTW, demangle.exp has 877 tests, but it covers four demangling styles:
gnu, lucid, arm, and hp.  So we are looking at 200-300 new tests,
not 900 new tests.

> >   gdb/59  static members in a base class confuse gdb
> Fixed. with a valops change i made a while ago.

I just tried this with this week's builds, and I'm getting an error:

  (gdb) p pB
  $1 = (B *) 0x8050538
  (gdb) p *pB
  Value can't be converted to integer.

Native Red Hat Linux 7, stabs, et cetera.

This is a different error than the bug reported in the PR.  Sigh.

> These bugs were always there, v3 just exposes them a heck of a lot
> more.  They used to be hard to see, and users would occasionally
> complain.
> Now it's right in their face, almost any time they use the standard
> library.

Yeah.  I claim that "v3 is almost better than v2".  But if v2 was
terrible, that still might not be very good.

From a scheduling point of view, JimB can fix a lot of bugs before
touching the dwarf2 reader.  From a release criteria point of view, I
just don't know how much scope work is necessary to have a shippable 5.1.

Michael

Re: So what is wrong with v3 C++

[Christopher Faylor]

On Thu, Jun 28, 2001 at 08:42:26PM -0700, Michael Elizabeth Chastain wrote:
>  (gdb) p pB
>  $1 = (B *) 0x8050538
>  (gdb) p *pB
>  Value can't be converted to integer.

FWIW, I've been getting these types of errors with a recent cygwin
version of gdb, too.

cgf

Re: So what is wrong with v3 C++

[Daniel Berlin]

Christopher Faylor <cgf@redhat.com> writes:

> On Thu, Jun 28, 2001 at 08:42:26PM -0700, Michael Elizabeth Chastain wrote:
>>  (gdb) p pB
>>  $1 = (B *) 0x8050538
>>  (gdb) p *pB
>>  Value can't be converted to integer.
> 
> FWIW, I've been getting these types of errors with a recent cygwin
> version of gdb, too.
> 
Hmmmm.
I wonder if it's actually caused by either rtti or baseclass_offset or
something.

Michael, can you send me a stack trace?

> cgf

-- 
"A while ago, I went skiing in England.  It was a rare package:
two weeks in England, one night in Connecticut, two weeks in
England.  I said, "Yes, I'll take it."  I got on this chairlift
with this guy I didn't know.  We went halfway up the mountain
without saying a word.  Then he turned to me and said, "You
know, this is the first time I've gone skiing in ten years."  I
said, "Why did you take such a long time off?"  He said, "I was
in prison.  Want to know why?"  I said, "Not really.  Well, you
better tell me why."  He said, "I pushed a total stranger off a
Ferris wheel."  I said, "I remember you."
"-Steven Wright

Re: So what is wrong with v3 C++

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

>> >   gdb/7   cout << 1 doesn't work for c++
>> This one is bogus.
>> It does work.
>> I poitned this out on gdb.bugs.
> 
> No.  You pointed out that it works with dwarf2.  You acknowledged
> that it doesn't work with stabs.  
Ahh, yes, now i remember.

My bad.
> You wrote:
> 
>   http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=23&database=gdb
> 
>   As did I, look for the posting where i showed it worked for me with
>   dwarf2 on both ppc, and x86.
> 
>   It doesn't work on stabs for one of two reasons:
>   ....
> 
>> >   gdb/40  C++ template functions have return types in their names
>> Normal. They should.
>> Look at the ABI standard.
> 
> The problem is that a template function has a name such as
> "int add_two_values<int>(int, int)", whereas a normal function has a
> name such as "add_two_values(int, int)".  Note the return type at the
> beginning of the name.
> 
> Specifically:
> 
>   % c++filt
>   _Z14add_two_valuesIiET_S0_S0_
>   int add_two_values<int>(int, int)
>   _Z14add_two_valuesii
>   add_two_values(int, int)
> 
> This was also a problem with v2.
I'm telling you, it's done on purpose, it's not a bug.

> 
> I'm looking at section 5.1.2 of the ABI standard, "General Structure".
> The demangling grammar gets down to "unqualified source code identifier"
> in about ten productions, with no reference to the function return type.
> Can you quote me the part of the ABI standard that puts the return type
> before the name?

Before the name?
No.
In the name?
Sure.
Template functions always have the return type included.

"
 Whether the mangling of a function type includes the return type
 depends on the context and the nature of the function.
   The rules for deciding whether the return type is included are:
    1. Template functions (names or types) have return types encoded,
       with the exceptions listed below.
    2. Function types not appearing as part of a function name
       mangling, e.g. parameters, pointer types, etc., have return
       type encoded, with the exceptions listed below.
    3. Non-template function names do not have return types encoded.
   The exceptions mentioned in (1) and (2) above, for which the return
   type is never included, are
     * Constructors.
     * Destructors.
     * Conversion operator functions, e.g. operator int.
"

Where the demangler places them is not going to be mandated by the ABI
standard.
Only when the return type of a function goes in the mangled name.

Function return types in C and C++ go before the function name in the
source, thus, this is where the demangler places them.

You seem to want to get rid of return types from mangled names for
templates. This ain't gonna ever happen. It's done on purpose, it's
not an accident.


>> libiberty already has demangler coverage for the demangler, why do we
>> need it in gdb as well?
> 
> Gdb is the #1 client of the demangler 

Really?
I just don't feel that way.

LD, c++filt, nm, objdump, etc all use it.
GDB seems to *depend* on it more, but this is not a good thing. We
depend on mangled names too much.
> 
> The second reason is that libiberty/testsuite/demangle-expected has
> only five cases that start with "_Z", and they are all --format=java.
> So we actually have very little v3 coverage right now.
> 
> BTW, demangle.exp has 877 tests, but it covers four demangling styles:
> gnu, lucid, arm, and hp.  So we are looking at 200-300 new tests,
> not 900 new tests.

The difference is that the new demangler is much easier to debug, and
recursive descent on a known grammar, as a result, fixing bugs in it
are basically guaranteed to not cause other things mysterious to
happen.
Each grammar production is completely localized to one routine.

> 
>> >   gdb/59  static members in a base class confuse gdb
>> Fixed. with a valops change i made a while ago.
> 
> I just tried this with this week's builds, and I'm getting an error:
> 
>   (gdb) p pB
>   $1 = (B *) 0x8050538
>   (gdb) p *pB
>   Value can't be converted to integer.
> 
> Native Red Hat Linux 7, stabs, et cetera.

> 
> This is a different error than the bug reported in the PR.  Sigh.
Yup.

> 
>> These bugs were always there, v3 just exposes them a heck of a lot
>> more.  They used to be hard to see, and users would occasionally
>> complain.
>> Now it's right in their face, almost any time they use the standard
>> library.
> 
> Yeah.  I claim that "v3 is almost better than v2".  But if v2 was
> terrible, that still might not be very good.
> 
>>From a scheduling point of view, JimB can fix a lot of bugs before
> touching the dwarf2 reader.  From a release criteria point of view, I
> just don't know how much scope work is necessary to have a shippable
> 5.1.

I've already rewritten the dwarf2 reader, including the scope work.
There would be little point in JimB rewriting it again.

> 
> Michael

-- 
"One time I went to a museum where all the work in the museum had
been done by children.  They had all the paintings up on
refrigerators.
"-Steven Wright

Re: So what is wrong with v3 C++

[Tom Tromey]

>>>>> ">" == Michael Elizabeth Chastain <chastain@cygnus.com> writes:

>> Gdb is the #1 client of the demangler so it's in our interest to
>> check for demangling bugs in our test suite.  That way we can find
>> them and push them upstream more easily.

The history of the libiberty test suite is that, in the past, people
would modify the demangler without running the gdb test suite.  Then
one day someone would do that and they would notice a bug.

So, I used some Emacs code to convert the gdb demangler test suite to
something I could put into libiberty.  My desire was that people
working on the demangler would be encouraged to write new tests there,
and that having the demangler pass its regressions would be a
requirement for any demangler change.

Unfortunately nobody wrote new tests as they wrote new code.  I think
I mentioned the test suite to whoever wrote the new demangler, but was
ignored.  Anyway I do think that the other goal still applies.
Putting new tests in gdb is, imnsho, not as helpful as putting them
into the demangler's own test suite.

I don't think pushing these things upstream is easier if you put the
test into the gdb framework.  It is easy to put a test into the
libiberty harness.  If there is an administrative overhead that makes
this hard, then that is the barrier that should be lowered.

Tom

Re: So what is wrong with v3 C++

[Benjamin Kosnik]

> "If I make this change, will it break our GCC 3.0 support?  I don't
> have GCC 3.0 installed anywhere anymore..."

I thought 'gcc-3' support was broken anyway. That was the whole point
of the initial post.

> But until someone fixes stabs, I think it's reasonable to tell C++
> users that GCC only provides sufficient information when using Dwarf
> 2.

I think this is reasonable as well, and I think you'll find that most
C++ users are already doing this by configuring with --with-dwarf2. I
am willing to do the appropriate configure/documenation work to make
--enable-languages=c++ deal with this sanely.

I also think it's reasonable to try and get this working first, then
figure out how to back-port it to gcc-3 and/or older gdb
versions. Hopefully, if this work gets done somewhat quickly, the
compiler support should be in the gcc-3.01 release.

thanks again dudes,
benjamin

Re: So what is wrong with v3 C++

[Benjamin Kosnik]

Y'all, I appreciate effort to fix C++ and make gdb usable for that
language.

Note, since we're at it, you might as well ask the Java people about
outstanding issues. Fixing many of the C++ related ones will most
probably help out Java as well, for those with an aversion to
C++. (This scoping stuff seems to be endemic to both java and C++.)


Other bugs, not mentioned in this thread.

1) cannot print contents of non-POD static data members reliably.
Hell, I most of the times I cannot print 'static const int' within a
class or nested class. This is the perennial 'cannot address memory
0x' bug. I've been reporting this for over 6 months.

2) cannot call static member functions with a fully qualified name.
ie
(gdb) p cout::sync_with_stdio(true)

For what it's worth, I've used gdb + an older version of Daniel's new
dwarf2 reader and it is better about the first of these things. It's
not been integrated, and the sources are sufficiently out of date that
it's a bit painful to use. I do keep this debugger around still, and
use it, it's quite nice.

I'm sure if you cross-post this message to libstdc++@gcc.gnu.org other
C++ programmers could give y'all more input. Pure chance (and the web
archive) introduced this thread to me. In the meantime, I'll post a
message to the library list pointing interested parties over to this
thread.

-benjamin

Re: So what is wrong with v3 C++

[Per Bothner]

Benjamin Kosnik <bkoz@redhat.com> writes:

> Note, since we're at it, you might as well ask the Java people about
> outstanding issues. Fixing many of the C++ related ones will most
> probably help out Java as well, for those with an aversion to
> C++. (This scoping stuff seems to be endemic to both java and C++.)

Absolutely.

Almost all of the Java ABI used by GCJ is defined as a subset of
the C++ ABI.  The main exception is handling of "interface inheritance"
and "interface method calls".  A Java interface is basically a
C++ virtual abstract base class with no non-static fields, but it is
implemented in a way that doesn't need "virtual bases" or offset
adjustment.

For example fixing support for namespaces would be very helpful
for Java, as Java classes are organized into packages - which are
basically namespaces.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: So what is wrong with v3 C++

[Michael Elizabeth Chastain]

Daniel Berlin writes:

> The thing is, it shouldn't match against demangled forms, it should
> match against *fully qualified* forms.

Ah, I feel some illumination coming on.

> Aclass a;
> int c;
> c = int a::george(int, int)(5, 6);
> 
> That's what we've got now.

gdb's goal is to have an expression evaluator that is some reasonable
subset of the language under test.

In K & R C, the translation from "demangled" -> "fully qualified" is trivial.
In ANSI C, the translation from "demangled" -> "fully qualified" takes work.
  You have to convert "foo(int, int)" -> "foo".
  This conversion is actually built into a string matcher!
In C++, the translation from "demangled" -> "fully qualified" is hairy.
  There are a lot of cases and changing the string matchers is hopeless.

It sounds like we need a much more detailed demangler interface, where
the demangler gives us the demangled name, the fully qualified name,
plus any other forms of the name we care about.

Michael

Re: So what is wrong with v3 C++

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Daniel Berlin writes:
> 
>> The thing is, it shouldn't match against demangled forms, it should
>> match against *fully qualified* forms.
> 
> Ah, I feel some illumination coming on.
> 
>> Aclass a;
>> int c;
>> c = int a::george(int, int)(5, 6);
>> 
>> That's what we've got now.
> 
> gdb's goal is to have an expression evaluator that is some reasonable
> subset of the language under test.
> 
> In K & R C, the translation from "demangled" -> "fully qualified" is trivial.
> In ANSI C, the translation from "demangled" -> "fully qualified" takes work.
>   You have to convert "foo(int, int)" -> "foo".
>   This conversion is actually built into a string matcher!
> In C++, the translation from "demangled" -> "fully qualified" is hairy.
>   There are a lot of cases and changing the string matchers is hopeless.
> 
> It sounds like we need a much more detailed demangler interface, where
> the demangler gives us the demangled name, the fully qualified name,
> plus any other forms of the name we care about.

Yup, this is what would be necessary to
1. Make the STABS reader be able to give qualified names, except in
   the case of namespaces (which it still wouldn't be able to do,
   without more hacks from gcc)
2. Make the new dwarf2 reader backwards compatible without having to
   use linkage names at anything more than symbol reading time (we can
   currently be backwards compatible by falling back on the linkage
   name, and doing what we used to, which is, use it).


> 
> Michael

-- 
"Last time I went to the movies I was thrown out for bringing my
own food.  My argument was that the concession stand prices are
outrageous.  Besides, I haven't had a Bar-B-Que in a long time.
"-Steven Wright

Re: So what is wrong with v3 C++

[Michael Elizabeth Chastain]

Hi Tom,

> Unfortunately nobody wrote new tests as they wrote new code.  I think
> I mentioned the test suite to whoever wrote the new demangler, but was
> ignored.  Anyway I do think that the other goal still applies.
> Putting new tests in gdb is, imnsho, not as helpful as putting them
> into the demangler's own test suite.

Pro:
  Modularity suggests that the test suite goes with the software.
  Parsimony suggests that the test appear in just one place.

Con:
  Defensiveness suggests that gdb tests this library facility that it needs.
  Ecology suggests that it get tested where people are actually testing.

> If there is an administrative overhead that makes this hard, then that
> is the barrier that should be lowered.

I think of it as "ecology" rather than "administration".
Gdb people are used to running only the gdb test suite.

I just tried this in one of my build trees:

  % cd native/build/libiberty
  % make check
  /bin/sh /horton/chastain/fsf/2001-06-23/source/libiberty/testsuite/regress-demangle /horton/chastain/fsf/2001-06-23/source/libiberty/testsuite/demangle-expected
  All 645 tests passed

I wrote another trivial script.  I'll add this to my Sunday reports.

Michael

Re: So what is wrong with v3 C++

[Michael Elizabeth Chastain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7658 bytes --]

Yeah, here's a typescript of the whole megillah.

MichaelC

===

Script started on Thu Jun 28 22:44:46 2001
[chastain@snapon tmp]$ echo $PATH
/horton/chastain/fsf/2001-06-23/snapon/native/install/bin:/bin:/usr/bin
[chastain@snapon tmp]$ cat x1.cc
class A
{
  public:
    A();
    virtual ~A();
    static int i;
};

A::A()
{
  ;
}

A::~A()
{
  ;
}

int A::i = 1;

class B : public A
{
  public:
    B();
    virtual ~B();
    static int j;
    static int k;
};

B::B()
{
  ;
}

B::~B()
{
  ;
}

int B::j = 2;
int B::k = 3;

int main ()
{
  B * pB = new B;
  delete pB;
}
[chastain@snapon tmp]$ g++ -v
Reading specs from /horton/chastain/fsf/2001-06-23/snapon/native/install/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/specs
Configured with: /horton/chastain/fsf/2001-06-23/source/configure --prefix=/horton/chastain/fsf/2001-06-23/snapon/native/install --disable-shared --enable-languages=c,c++,f77 --with-gnu-as --with-as=/horton/chastain/localdisk/snapon/baseline/binutils-2.11.2/native/install/bin/as --with-gnu-ld --with-ld=/horton/chastain/localdisk/snapon/baseline/binutils-2.11.2/native/install/bin/ld --enable-gdbmi
Thread model: single
gcc version 3.0.1 20010623 (prerelease)
[chastain@snapon tmp]$ g++ -g -o x1.exe x1.cc
[chastain@snapon tmp]$ gdb -v
GNU gdb 2001-06-24-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".
[chastain@snapon tmp]$ gdb gdb
GNU gdb 2001-06-24-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) set prompt [top] 
[top] set args x1.exe
[top] break error
Breakpoint 1 at 0x80d4556: file /horton/chastain/fsf/2001-06-23/source/gdb/utils.c, line 653.
[top] run
Starting program: /horton/chastain/fsf/2001-06-23/snapon/native/install/bin/gdb x1.exe
GNU gdb 2001-06-24-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 main
Breakpoint 1 at 0x80488b6: file x1.cc, line 45.
(gdb) run
Starting program: /home/chastain/tmp/x1.exe 

Breakpoint 1, main () at x1.cc:45
45	  B * pB = new B;
(gdb) next
46	  delete pB;
(gdb) ptype pB
type = class B : public A {
  public:
    static int j;
    static int k;

    B & operator=(B const&);
    B(B const&);
    B(B const&);
    B();
    B();
    ~B();
    virtual ~B();
    virtual ~B();
} *
(gdb) print pB
$1 = (B *) 0x8050538
(gdb) print *pB

Breakpoint 1, error (string=0x819d620 "Value can't be converted to integer.")
    at /horton/chastain/fsf/2001-06-23/source/gdb/utils.c:653
653	  va_start (args, string);
[top] bt
#0  error (string=0x819d620 "Value can't be converted to integer.")
    at /horton/chastain/fsf/2001-06-23/source/gdb/utils.c:653
#1  0x0807445d in unpack_long ()
    at /horton/chastain/fsf/2001-06-23/source/gdb/values.c:661
#2  0x0807428e in value_as_pointer (val=0x84e9968)
    at /horton/chastain/fsf/2001-06-23/source/gdb/values.c:602
#3  0x0812dd90 in gnuv3_rtti_type (value=0x84f3e38, full_p=0xbffff0d8, 
    top_p=0xbffff0dc, using_enc_p=0xbffff0e0)
    at /horton/chastain/fsf/2001-06-23/source/gdb/gnu-v3-abi.c:211
#4  0x080d7a71 in value_rtti_type (v=0x84f3e38, full=0xbffff0d8, 
    top=0xbffff0dc, using_enc=0xbffff0e0)
    at /horton/chastain/fsf/2001-06-23/source/gdb/cp-abi.c:76
#5  0x0807d649 in value_full_object (argp=0x84f3e38, rtype=0x0, xfull=0, 
    xtop=0, xusing_enc=0)
    at /horton/chastain/fsf/2001-06-23/source/gdb/valops.c:3158
#6  0x0807a9cd in value_ind (arg1=0x84960f8)
    at /horton/chastain/fsf/2001-06-23/source/gdb/valops.c:1016
#7  0x08078655 in evaluate_subexp_standard (expect_type=0x0, exp=0x84e9910, 
    pos=0xbffff3c4, noside=EVAL_NORMAL)
    at /horton/chastain/fsf/2001-06-23/source/gdb/eval.c:1620
#8  0x0807532b in evaluate_subexp (expect_type=0x0, exp=0x84e9910, 
    pos=0xbffff3c4, noside=EVAL_NORMAL)
    at /horton/chastain/fsf/2001-06-23/source/gdb/eval.c:69
---Type <return> to continue, or q <return> to quit---
#9  0x080754ee in evaluate_expression (exp=0x84e9910)
    at /horton/chastain/fsf/2001-06-23/source/gdb/eval.c:158
#10 0x08083132 in print_command_1 (exp=0x8220416 "*pB", inspect=0, voidprint=1)
    at /horton/chastain/fsf/2001-06-23/source/gdb/printcmd.c:918
#11 0x08083323 in print_command (exp=0x8220416 "*pB", from_tty=1)
    at /horton/chastain/fsf/2001-06-23/source/gdb/printcmd.c:981
#12 0x080d22d3 in execute_command (p=0x8220418 "B", from_tty=1)
    at /horton/chastain/fsf/2001-06-23/source/gdb/top.c:789
#13 0x0809d97d in command_handler (command=0x8220410 "print *pB")
    at /horton/chastain/fsf/2001-06-23/source/gdb/event-top.c:513
#14 0x0809de43 in command_line_handler (rl=0x84a8c88 "(\013#\bðA\r\büóÿ¿\021")
    at /horton/chastain/fsf/2001-06-23/source/gdb/event-top.c:809
#15 0x08188a26 in rl_callback_read_char ()
    at /horton/chastain/fsf/2001-06-23/source/readline/callback.c:114
#16 0x0809d86f in stdin_event_handler (error=0, client_data=0x0)
    at /horton/chastain/fsf/2001-06-23/source/gdb/event-top.c:420
#17 0x080eb8b7 in handle_file_event (event_file_desc=0)
    at /horton/chastain/fsf/2001-06-23/source/gdb/event-loop.c:706
#18 0x080eb34e in process_event ()
    at /horton/chastain/fsf/2001-06-23/source/gdb/event-loop.c:335
#19 0x080eb39b in gdb_do_one_event (data=0x0)
    at /horton/chastain/fsf/2001-06-23/source/gdb/event-loop.c:372
#20 0x080d1e8a in catch_errors (func=0x80eb370 <gdb_do_one_event>, args=0x0, 
---Type <return> to continue, or q <return> to quit---
    errstring=0x81c6800 "", mask=6)
    at /horton/chastain/fsf/2001-06-23/source/gdb/top.c:472
#21 0x080eb3d3 in start_event_loop ()
    at /horton/chastain/fsf/2001-06-23/source/gdb/event-loop.c:396
#22 0x08070861 in captured_command_loop (data=0x0)
    at /horton/chastain/fsf/2001-06-23/source/gdb/main.c:102
#23 0x080d1e8a in catch_errors (func=0x8070850 <captured_command_loop>, 
    args=0x0, errstring=0x819ba82 "", mask=6)
    at /horton/chastain/fsf/2001-06-23/source/gdb/top.c:472
#24 0x08071073 in captured_main (data=0xbffff970)
    at /horton/chastain/fsf/2001-06-23/source/gdb/main.c:724
#25 0x080d1e8a in catch_errors (func=0x80708a0 <captured_main>, 
    args=0xbffff970, errstring=0x819ba82 "", mask=6)
    at /horton/chastain/fsf/2001-06-23/source/gdb/top.c:472
#26 0x080712d7 in main (argc=2, argv=0xbffff9e4)
    at /horton/chastain/fsf/2001-06-23/source/gdb/main.c:735
#27 0x400a0b65 in __libc_start_main (main=0x80712b0 <main>, argc=2, 
    ubp_av=0xbffff9e4, init=0x806fc68 <_init>, fini=0x819b950 <_fini>, 
    rtld_fini=0x4000df24 <_dl_fini>, stack_end=0xbffff9dc)
    at ../sysdeps/generic/libc-start.c:111
[top] cont
Continuing.
Value can't be converted to integer.
(gdb) cont
Continuing.

Program exited normally.
(gdb) quit

Program exited normally.
[top] quit
[chastain@snapon tmp]$ exit
exit

Script done on Thu Jun 28 22:46:27 2001

Re: So what is wrong with v3 C++

[Daniel Berlin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8265 bytes --]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

Blingo.
gnuv3_rtti_type isn't quite right in some way.


> Yeah, here's a typescript of the whole megillah.
> 
> MichaelC
> 
> ===
> 
> Script started on Thu Jun 28 22:44:46 2001
> [chastain@snapon tmp]$ echo $PATH
> /horton/chastain/fsf/2001-06-23/snapon/native/install/bin:/bin:/usr/bin
> [chastain@snapon tmp]$ cat x1.cc
> class A
> {
>   public:
>     A();
>     virtual ~A();
>     static int i;
>};
> 
> A::A()
> {
>   ;
>}
> 
> A::~A()
> {
>   ;
>}
> 
> int A::i = 1;
> 
> class B : public A
> {
>   public:
>     B();
>     virtual ~B();
>     static int j;
>     static int k;
>};
> 
> B::B()
> {
>   ;
>}
> 
> B::~B()
> {
>   ;
>}
> 
> int B::j = 2;
> int B::k = 3;
> 
> int main ()
> {
>   B * pB = new B;
>   delete pB;
>}
> [chastain@snapon tmp]$ g++ -v
> Reading specs from /horton/chastain/fsf/2001-06-23/snapon/native/install/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/specs
> Configured with: /horton/chastain/fsf/2001-06-23/source/configure --prefix=/horton/chastain/fsf/2001-06-23/snapon/native/install --disable-shared --enable-languages=c,c++,f77 --with-gnu-as --with-as=/horton/chastain/localdisk/snapon/baseline/binutils-2.11.2/native/install/bin/as --with-gnu-ld --with-ld=/horton/chastain/localdisk/snapon/baseline/binutils-2.11.2/native/install/bin/ld --enable-gdbmi
> Thread model: single
> gcc version 3.0.1 20010623 (prerelease)
> [chastain@snapon tmp]$ g++ -g -o x1.exe x1.cc
> [chastain@snapon tmp]$ gdb -v
> GNU gdb 2001-06-24-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".
> [chastain@snapon tmp]$ gdb gdb
> GNU gdb 2001-06-24-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) set prompt [top] 
> [top] set args x1.exe
> [top] break error
> Breakpoint 1 at 0x80d4556: file /horton/chastain/fsf/2001-06-23/source/gdb/utils.c, line 653.
> [top] run
> Starting program: /horton/chastain/fsf/2001-06-23/snapon/native/install/bin/gdb x1.exe
> GNU gdb 2001-06-24-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 main
> Breakpoint 1 at 0x80488b6: file x1.cc, line 45.
> (gdb) run
> Starting program: /home/chastain/tmp/x1.exe 
> 
> Breakpoint 1, main () at x1.cc:45
> 45	  B * pB = new B;
> (gdb) next
> 46	  delete pB;
> (gdb) ptype pB
> type = class B : public A {
>   public:
>     static int j;
>     static int k;
> 
>     B & operator=(B const&);
>     B(B const&);
>     B(B const&);
>     B();
>     B();
>     ~B();
>     virtual ~B();
>     virtual ~B();
>} *
> (gdb) print pB
> $1 = (B *) 0x8050538
> (gdb) print *pB
> 
> Breakpoint 1, error (string=0x819d620 "Value can't be converted to integer.")
>     at /horton/chastain/fsf/2001-06-23/source/gdb/utils.c:653
> 653	  va_start (args, string);
> [top] bt
> #0  error (string=0x819d620 "Value can't be converted to integer.")
>     at /horton/chastain/fsf/2001-06-23/source/gdb/utils.c:653
> #1  0x0807445d in unpack_long ()
>     at /horton/chastain/fsf/2001-06-23/source/gdb/values.c:661
> #2  0x0807428e in value_as_pointer (val=0x84e9968)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/values.c:602
> #3  0x0812dd90 in gnuv3_rtti_type (value=0x84f3e38, full_p=0xbffff0d8, 
>     top_p=0xbffff0dc, using_enc_p=0xbffff0e0)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/gnu-v3-abi.c:211
> #4  0x080d7a71 in value_rtti_type (v=0x84f3e38, full=0xbffff0d8, 
>     top=0xbffff0dc, using_enc=0xbffff0e0)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/cp-abi.c:76
> #5  0x0807d649 in value_full_object (argp=0x84f3e38, rtype=0x0, xfull=0, 
>     xtop=0, xusing_enc=0)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/valops.c:3158
> #6  0x0807a9cd in value_ind (arg1=0x84960f8)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/valops.c:1016
> #7  0x08078655 in evaluate_subexp_standard (expect_type=0x0, exp=0x84e9910, 
>     pos=0xbffff3c4, noside=EVAL_NORMAL)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/eval.c:1620
> #8  0x0807532b in evaluate_subexp (expect_type=0x0, exp=0x84e9910, 
>     pos=0xbffff3c4, noside=EVAL_NORMAL)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/eval.c:69
> ---Type <return> to continue, or q <return> to quit---
> #9  0x080754ee in evaluate_expression (exp=0x84e9910)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/eval.c:158
> #10 0x08083132 in print_command_1 (exp=0x8220416 "*pB", inspect=0, voidprint=1)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/printcmd.c:918
> #11 0x08083323 in print_command (exp=0x8220416 "*pB", from_tty=1)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/printcmd.c:981
> #12 0x080d22d3 in execute_command (p=0x8220418 "B", from_tty=1)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/top.c:789
> #13 0x0809d97d in command_handler (command=0x8220410 "print *pB")
>     at /horton/chastain/fsf/2001-06-23/source/gdb/event-top.c:513
> #14 0x0809de43 in command_line_handler (rl=0x84a8c88 "(\013#\bðA\r\büóÿ¿\021")
>     at /horton/chastain/fsf/2001-06-23/source/gdb/event-top.c:809
> #15 0x08188a26 in rl_callback_read_char ()
>     at /horton/chastain/fsf/2001-06-23/source/readline/callback.c:114
> #16 0x0809d86f in stdin_event_handler (error=0, client_data=0x0)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/event-top.c:420
> #17 0x080eb8b7 in handle_file_event (event_file_desc=0)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/event-loop.c:706
> #18 0x080eb34e in process_event ()
>     at /horton/chastain/fsf/2001-06-23/source/gdb/event-loop.c:335
> #19 0x080eb39b in gdb_do_one_event (data=0x0)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/event-loop.c:372
> #20 0x080d1e8a in catch_errors (func=0x80eb370 <gdb_do_one_event>, args=0x0, 
> ---Type <return> to continue, or q <return> to quit---
>     errstring=0x81c6800 "", mask=6)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/top.c:472
> #21 0x080eb3d3 in start_event_loop ()
>     at /horton/chastain/fsf/2001-06-23/source/gdb/event-loop.c:396
> #22 0x08070861 in captured_command_loop (data=0x0)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/main.c:102
> #23 0x080d1e8a in catch_errors (func=0x8070850 <captured_command_loop>, 
>     args=0x0, errstring=0x819ba82 "", mask=6)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/top.c:472
> #24 0x08071073 in captured_main (data=0xbffff970)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/main.c:724
> #25 0x080d1e8a in catch_errors (func=0x80708a0 <captured_main>, 
>     args=0xbffff970, errstring=0x819ba82 "", mask=6)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/top.c:472
> #26 0x080712d7 in main (argc=2, argv=0xbffff9e4)
>     at /horton/chastain/fsf/2001-06-23/source/gdb/main.c:735
> #27 0x400a0b65 in __libc_start_main (main=0x80712b0 <main>, argc=2, 
>     ubp_av=0xbffff9e4, init=0x806fc68 <_init>, fini=0x819b950 <_fini>, 
>     rtld_fini=0x4000df24 <_dl_fini>, stack_end=0xbffff9dc)
>     at ../sysdeps/generic/libc-start.c:111
> [top] cont
> Continuing.
> Value can't be converted to integer.
> (gdb) cont
> Continuing.
> 
> Program exited normally.
> (gdb) quit
> 
> Program exited normally.
> [top] quit
> [chastain@snapon tmp]$ exit
> exit
> 
> Script done on Thu Jun 28 22:46:27 2001

-- 
"Factorials were someone's attempt to make math *look* exciting.
"-Steven Wright

Re: So what is wrong with v3 C++

[Michael Elizabeth Chastain]

Dan Berlin writes:
> 1. Template functions (names or types) have return types encoded,
>    with the exceptions listed below.

Okay, we must comply with the ABI, then.

> You seem to want to get rid of return types from mangled names for
> templates. This ain't gonna ever happen. It's done on purpose, it's
> not an accident.

No, first I want to know what the spec requires.  The ABI spec wants the
information to be present in the mangled name.  Now follow the information
flow:

  mangled name -> demangled name (demangler)
  demangled name -> user visible and user matchable names (gdb)

I accept the ABI spec, and I'm comfortable with the demangler preserving
all the information including the return type.

We still have to figure out what to do if the user types:

  (gdb) break add_two_values

... when add_two_values is a template.

One option is to propagate this "return type in the name" all the way
through to the user, and mention it in the documentation.  So the
user really would have to type:

  (gdb) break 'int add_two_values<int,int>TAB

> LD, c++filt, nm, objdump, etc all use it.
> GDB seems to *depend* on it more, but this is not a good thing. We
> depend on mangled names too much.

nm, objdump, and c++filt just use demangling in their output.
As far as I know, ld operates the same way.  Does it ever demangle a name
and use the result for anything except error printing?

gdb is the only tool I know where people type in names and the tool
has to match against demangled forms.

If you are suggesting that the demangler should return a nice tree
of information, instead of gdb doing its own re-parsing, I'm in favor
of that.

> I've already rewritten the dwarf2 reader, including the scope work.
> There would be little point in JimB rewriting it again.

I saw the patch.

Do you have any test results, or plans for getting it tested?

Michael

Re: So what is wrong with v3 C++

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Dan Berlin writes:
>> 1. Template functions (names or types) have return types encoded,
>>    with the exceptions listed below.
> 
> Okay, we must comply with the ABI, then.
> 
>> You seem to want to get rid of return types from mangled names for
>> templates. This ain't gonna ever happen. It's done on purpose, it's
>> not an accident.
> 
> No, first I want to know what the spec requires.  The ABI spec wants the
> information to be present in the mangled name.  Now follow the information
> flow:
> 
>   mangled name -> demangled name (demangler)
>   demangled name -> user visible and user matchable names (gdb)
> 
> I accept the ABI spec, and I'm comfortable with the demangler preserving
> all the information including the return type.
> 
> We still have to figure out what to do if the user types:
> 
>   (gdb) break add_two_values
> 
> ... when add_two_values is a template.

Sure. 
What we really should be doing is something like find_methods, except
including templates.
That way, we could present a list like:

add_two_values<int, int>
add_two_values<float, int>

And let the user decide which ones they wanted breakpointed.

> 
> One option is to propagate this "return type in the name" all the way
> through to the user, and mention it in the documentation.  So the
> user really would have to type:
> 
>   (gdb) break 'int add_two_values<int,int>TAB
Oh, I see what you mean.

However, note, the new dwarf2 reader should fix this problem as well.

It was the reliance on mangled names that gave the return type.

Ah, yes.
Hand verified to be mostly fixed in the new d2 reader.

(gdb) b 'add_two_values<int>'
Breakpoint 1 at 0x10000830: file test2.cc, line 3.
(gdb)


There is a mismatch in the new d2 reader between psymbol names and
symbol names, because i haven't quite gotten scoping into the
psymbols.  So if you did "info func add", it would show
"int add_two_values<int> (int, int)".

However, this bug also causes b 'int add_two_values<int> (int, int)'
to work, just like it used to.
:)

STABS isn't possible to fix without generating it's own qualified
names, which won't work with namespaces.

So we'll probably need to document the difference anyway.

> 
>> LD, c++filt, nm, objdump, etc all use it.
>> GDB seems to *depend* on it more, but this is not a good thing. We
>> depend on mangled names too much.
> 
> nm, objdump, and c++filt just use demangling in their output.
> As far as I know, ld operates the same way.  Does it ever demangle a name
> and use the result for anything except error printing?

I have no idea. I'll check.
> 
> gdb is the only tool I know where people type in names and the tool
> has to match against demangled forms.

The thing is, it shouldn't match against demangled forms, it should
match against *fully qualified* forms.

When talking about symbols in C++, do you say "Yeah, look at the int
a::b(int a, int b) function." or "Yeah, look at the a::b function".

The whole reason we do demangled forms is because of limitations of
STABS (lack of namespace support, etc) that don't allow us to do full
qualified names.

However, using demangled forms gives us an interface that isn't quite
what the user expects, and causes us problems elsewhere.

It's okay to use the internally, but we really shouldn't expose them
to the user.

Think of it as if you had to write code like this:

int main(void)
{
        Aclass a;
        int c;
        c = int a::george(int, int)(5, 6);
}
That's what we've got now.

Of course, because STABS *won't* (IIRC, thinks like Third Eye do
support it) allow us to handle namespaces properly, I don't expect to
see this changed, and would fight it, for a few more years, until
STABS is much less prevalent.

> 
> If you are suggesting that the demangler should return a nice tree
> of information, instead of gdb doing its own re-parsing, I'm in favor
> of that.
> 
>> I've already rewritten the dwarf2 reader, including the scope work.
>> There would be little point in JimB rewriting it again.
> 
> I saw the patch.
> 
> Do you have any test results, or plans for getting it tested?

Yes. 
After I fix the known bugs, i'm going to start running the regression
tests and fixing those bugs.

Once we either end up with no regressions, or doing better than we
used to, i'll submit it for approval.

> 
> Michael

-- 
"I owed my friend George $25.  For about three weeks I owed it to
him.  The whole time I had the money on me -- he didn't know it.
Walking through New York City, 2:30 in the morning and got held
up.  He said, "Gimme all your money."  I said, "Wait a minute."
I said, "George, here's the 25 dollars I owe you."  The the
thief took a thousand dollars out of his own money and he gave
it to George.  At gunpoint made me borrow a thousand dollars
from George.
"-Steven Wright

Re: So what is wrong with v3 C++

[Michael Elizabeth Chastain]

Here are the open PR's:

  gdb/7   cout << 1 doesn't work for c++
  gdb/18  gdb can't parse "info func operator*" or "info func operator\*"
  gdb/19  gdb v3 demangler fails on hairyfunc5 hairyfunc6 hairyfunc7
  gdb/27  ptype shows duplicate constructors and destructors
  gdb/33  name matching on template names is sensitive to white space
  gdb/34  g++ v3 functions show as "inheritance2() ()"
  gdb/39  C++ constructors show bogus return type
  gdb/40  C++ template functions have return types in their names
  gdb/41  testsuite/gdb.c++/demangle.exp needs v3 coverage
  gdb/57  nested classes incorrectly printing
  gdb/59  static members in a base class confuse gdb
  gdb/60  GDB has problems with C++ symbols

As I've talked about with JimB, PR gdb/27 requires new design in gdb.
The issue is that gcc takes one source function (a constructor or a
destructor) and emits two or three object code functions for it.  This
is new in g++ v3, and as far as I know, gdb has never had machinery to
handle anything like this.  All the rest of the PR's are simply bugs.

Some of the template stuff and namespace stuff may require new design.
Probably every case that is broken in v3 was already broken in v2.

Pointers-to-members probably don't work.  There is a test script
gdb.c++/member-ptr.exp that is disabled with the following comment:

  # Nearly all of these tests fail when compiled with G++, so just give up
  # until GDB gets enhanced. -sts 1999-06-22

Here are the bugs that I haven't filed PR's on yet.  I'll just bite the
bullet and file some PR's tonight.

  function call with reference parameter
  fails in gdb.c++/classes.exp
  fails in both v2.95.3 and v3pre

    When the test script calls a function by hand, and the function
    has a reference parameter, the inferior program gets a SIGSEGV.

  user accesses ambiguous base
  fails in gdb.c++/inherit.exp
  fails in both v2.95.3 and v3pre

    The program under test has a non-virtual base class which appears
    several times (B:A and C:A and D:B,C so D has two A's).  The debugger
    when the user references a member such as "d::a", gdb should say
    that this is ambiguous.  Instead, gdb uses the first one that it
    finds.

  gdb value for some arguments at beginning of function
  fails in gdb.c++/overload.exp
  passes in v2.95.3, fails in v3pre

    Argument values are incorrect when calling a function with an
    arg of type short, unsigned short, long, or unsigned long.

  user sets breakpoint on template class ctor/dtor
  fails in gdb.c++/templates.exp
  results lost for v.29.3, fails in v3pre

    The test script attempts to set breakpoints on "T5<int>::T5"
    and "T5<int>::~T5".  gdb fails to find these functions.

> My second question.  How many of these bugs can be fixed without 
> rewriting the dwarf2 reader?  My understanding is that both the virtual 
> functions and the thunks bugs can.

I think so too.  There's a big issue with finding and using the virtual
base pointers properly.  As I understand it, Jim's going to rewrite this
code.  Then if the code has problems, we will:

  . check the assembly code of the program-under-test against the
    Intel spec.  If the assembly code does not conform, file an
    upstream PR against gcc.

  . if the assembly code does conform, debug the new v3 code that
    implements stuff like baseclass_offset.

Another way to look it: I don't think any of the *new* v3 bugs are in
the dwarf2 reader.

Michael

Re: So what is wrong with v3 C++

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Here are the open PR's:
> 
>   gdb/7   cout << 1 doesn't work for c++
This one is bogus.
It does work.
I poitned this out on gdb.bugs.

>   gdb/18  gdb can't parse "info func operator*" or "info func
>   operator\*"
parser bug.
>   gdb/19  gdb v3 demangler fails on hairyfunc5 hairyfunc6 hairyfunc7
demangler bug.
>   gdb/27  ptype shows duplicate constructors and destructors
Needs redesign of parts of gdb.

>   gdb/33  name matching on template names is sensitive to white
>   space
>   gdb/34  g++ v3 functions show as "inheritance2() ()"
Demangler bug.

>   gdb/39  C++ constructors show bogus return type
Scoping bug.

>   gdb/40  C++ template functions have return types in their names
Normal. They should.
Look at the ABI standard.

>   gdb/41  testsuite/gdb.c++/demangle.exp needs v3 coverage
libiberty already has demangler coverage for the demangler, why do we
need it in gdb as well?

>   gdb/57  nested classes incorrectly printing
Scoping bug.

>   gdb/59  static members in a base class confuse gdb
Fixed. with a valops change i made a while ago.

>   gdb/60  GDB has problems with C++ symbols
Scoping bug.

> 
> As I've talked about with JimB, PR gdb/27 requires new design in gdb.
> The issue is that gcc takes one source function (a constructor or a
> destructor) and emits two or three object code functions for it.  This
> is new in g++ v3, and as far as I know, gdb has never had machinery to
> handle anything like this.  All the rest of the PR's are simply bugs.
> 
> Some of the template stuff and namespace stuff may require new design.
> Probably every case that is broken in v3 was already broken in v2.
> 
Yes.
> 
>   user accesses ambiguous base
>   fails in gdb.c++/inherit.exp
>   fails in both v2.95.3 and v3pre
> 
>     The program under test has a non-virtual base class which appears
>     several times (B:A and C:A and D:B,C so D has two A's).  The debugger
>     when the user references a member such as "d::a", gdb should say
>     that this is ambiguous.  Instead, gdb uses the first one that it
>     finds.

I've got this one fixed.
Patch forthcoming.
It took me a while to take HP's code to do this, and make it look
reasonable.
:)
> 
> Another way to look it: I don't think any of the *new* v3 bugs are in
> the dwarf2 reader.

Sure.
I'll give you that.
These bugs were always there, v3 just exposes them a heck of a lot
more.  They used to be hard to see, and users would occasionally
complain.
Now it's right in their face, almost any time they use the standard
library.

Anything marked scoping bug requires the dwarf2 reader rewrite.
You could hack the stabs reader to be better, but it would take some
work. And you can't actually fix the real cause.
:(


> Michael

-- 
"I used to be a waiter, but I was fired for clearing tables.  I
was clearing them for take off.  I had them all lined up
outside.  People thought it was an outdoor cafe.  I said, "No,
these are leaving at 3."  They were going to fire me anyway,
because I told them I thought they should put the wrapper on the
inside of the straw since that's the part you don't want to get
dirty.
"-Steven Wright

So what is wrong with v3 C++

[Andrew Cagney]

So,

[Perhaphs I should write a book about how I'm a reformed C++ programmer 
... :-)]

At the risk of ``playing manager'', I'd like to try to understand 
exactly what the problems with GDB v3.0 are.  If nothing else, I, or 
someone else, will need to document these as known bugs in the 5.1 
release notes.  Further, since C++ no longer has a maintainer, I think 
that now is probably a good time to take stock.


Anyway, to this end, I had a face to face discussion with Jim Blandy 
(Don and a few others were present and were contibuting, unfortunatly, 
neither DanB nor Michael C were around).

In that discussion, my attention was drawn to the following v3 C++ problems:


> - Dwarf 2 reader: fix constructor stuff
>   ( http://sources.redhat.com/ml/gdb/2001-06/msg00096.html )


While this has been discussed to death and causes many many failures and 
a fix involves changes to the dwarf2 reader.  I'm left wondering if:

	o	it really needs a dwarf2 rewrite

	o	compared to some of the other
		bugs, it is really that urgent

Personally, I'd be more worried about being able to single step and 
print variables correctly.



> - Virtual base classes, and their virtual functions


This, I understand is more serious.  GDB does need to be able to print 
out virtual base classes, their functions and so on.  I understand that, 
at present, it prints out bogus information.

Going by what Jim indicated, though, this in theory just involves more 
foot leather - finding the time to fill in the missing cases.  I suspect 
that who ever does do this will need very thick soles on their shoes.


> - Skipping vtable thunks, if necessary


I don't know if this was ever discussed on this list.  As I understand 
it, v3 virtual function is sometimes called via a ``thunk''.  A 
``thunk'' pulls a rabbit out of a hat (finds the correct object to pass 
to the real function) and then passes control to the real function.

At present, if GDB stepped into a thunk it would find no line info, 
treat it like a library and just skip it - oops, step into virtual 
functions via thunks doesn't work.

One proposed solution is to mimic / generalize the shared library 
mechanism so that GDB will single step through it to the real function.

I think this bug is pretty serious since, GDB will, randomly loose 
control over the target.  I certainly think it is more serious than the 
constructor problem.


> - Breakpoint work?


This one I don't remember.  There was a question if, given an arbitrary 
C++ expression, GDB could find and set a breakpoint on the correct function.


> - decode_line_1


This one has been discussed to death.  The current decode_line_1 is 
un-maintainable.  However, people, are largely living with it.


So my first question.  Are there any other serious v3 bugs?  MichaelC, 
you're probably most familar with the testsuite and what it is reporting 
as broken.

My second question.  How many of these bugs can be fixed without 
rewriting the dwarf2 reader?  My understanding is that both the virtual 
functions and the thunks bugs can.

enjoy,
	Andrew

Re: So what is wrong with v3 C++

[Daniel Berlin]

Andrew Cagney <ac131313@cygnus.com> writes:

> So,
> 
> [Perhaphs I should write a book about how I'm a reformed C++
> programmer ... :-)]
> 
> 
> At the risk of ``playing manager'', I'd like to try to understand
> exactly what the problems with GDB v3.0 are.  If nothing else, I, or
> someone else, will need to document these as known bugs in the 5.1
> release notes.  Further, since C++ no longer has a maintainer, I think
> that now is probably a good time to take stock.
Sure, i'll avoid discussion of other problems, and just stick the v3
ones, so that i don't end up writing a novel.
:)

> 
> 
> 
> Anyway, to this end, I had a face to face discussion with Jim Blandy
> (Don and a few others were present and were contibuting, unfortunatly,
> neither DanB nor Michael C were around).
> 
> 
> In that discussion, my attention was drawn to the following v3 C++ problems:
> 
> 
>> - Dwarf 2 reader: fix constructor stuff
>>   ( http://sources.redhat.com/ml/gdb/2001-06/msg00096.html )
> 
> 
> While this has been discussed to death and causes many many failures
> and a fix involves changes to the dwarf2 reader.  I'm left wondering
> if:
> 
> 
> 	o	it really needs a dwarf2 rewrite
Yes.
There is no other way to do it properly.  
The constructors involved have no mangled name, so you need to be able
to generate a fully qualified name. You couldn't do this easily
without rewriting most of the dwarf2 reader anyway, and as i'll
explain a little below, it's badly in need of a rewrite anyway.

To put it into a picture, it looks like this:


DW_TAG_class:
        DW_AT_name: bob
        ...
        DW_TAG_member:
                DW_AT_name: bob
        ...
DW_TAG_subroutine:
        DW_AT_specification: <pointer to the bob member>
        ...

See, normally, their is a very bad hack involved here so that we don't
just call the thing inside the class "bob", we call it "bob::bob".

This is the DW_AT_mips_linkage_name hack.  It gives a mangled name.
The mangled name, once demangled, is fully qualified.  We use this
hack (which doesn't even work completely) to get some semblance of a
right name.

However, since the *real* constructor subroutine die (the one outside
the class) points to a die inside the class, which has no
linkage_name, we call the constructor "bob" (if an attribute doesn't
exist in the same die, you see if it exists in the specification die).

The inside the class constructor *can't* have a linkage name.  It's
really two different constructors, and doesn't exist for real.

But because we rely on mangled names to give us the qualified names,
instead of *scoping*, we give the name "bob" to the constructor.

In other words, we've always had this problem, it just wasn't so damn
easy to see before.


> 
> 	o	compared to some of the other
> 		bugs, it is really that urgent
> 
> Personally, I'd be more worried about being able to single step and
> print variables correctly.

You can't do either with the scoping problems involved.
Read benjamin's bug report from yesterday.

> 
> 
> 
> 
>> - Virtual base classes, and their virtual functions
> 
> 
> This, I understand is more serious.  GDB does need to be able to print
> out virtual base classes, their functions and so on.  I understand
> that, at present, it prints out bogus information.
> 
> 
> Going by what Jim indicated, though, this in theory just involves more
> foot leather - finding the time to fill in the missing cases. 

Sure.
>  I
> suspect that who ever does do this will need very thick soles on their
> shoes.
> 
> 
> 
>> - Skipping vtable thunks, if necessary
> 
> 
> I don't know if this was ever discussed on this list.  As I understand
> it, v3 virtual function is sometimes called via a ``thunk''.  A
> ``thunk'' pulls a rabbit out of a hat (finds the correct object to
> pass to the real function) and then passes control to the real
> function.
> 
> 
> At present, if GDB stepped into a thunk it would find no line info,
> treat it like a library and just skip it - oops, step into virtual
> functions via thunks doesn't work.
> 
> 
> One proposed solution is to mimic / generalize the shared library
> mechanism so that GDB will single step through it to the real
> function.
> 
> 
> I think this bug is pretty serious since, GDB will, randomly loose
> control over the target.  I certainly think it is more serious than
> the constructor problem.

Sure.
But the constructor problem is caused by a much larger problem, of
arguably equal importance.
That is, the lack of proper qualifying of names done by the dwarf2
reader.

Note that the STABS reader is hopeless in this regard.
It'll always have to depend on mangled names, and thus, you can't do
anything about the generation of qualified names.

> 
> 
> 
>> - Breakpoint work?
> 
> 
> This one I don't remember.  There was a question if, given an
> arbitrary C++ expression, GDB could find and set a breakpoint on the
> correct function.

Yes, but only thanks to overloading support.

It doesn't, however, do it automatically, and it could.

> 
> 
> 
>> - decode_line_1
> 
> 
> This one has been discussed to death.  The current decode_line_1 is
> un-maintainable.  However, people, are largely living with it.
> 
> 
> 
> So my first question.  Are there any other serious v3 bugs? 

Yes.
The scoping problems caused by the way the current dwarf2 reader does
it's thing cause us to misname variables, functions, nested classes,
you name it.

As benjamin's simple case shows, you end up with numpunct<char>
instead of std::numpunct<char>.

Their is also the problem that baseclasses will not be offset properly
all the time.  So printing out variables of a class type may display
completely bogus info.

IE

(gdb) print a
{<A> = { a = 598713412, b=5917212}}

Where a and b should be "6" and "3".
:)


>  MichaelC,
> you're probably most familar with the testsuite and what it is
> reporting as broken.
> 
> 
> My second question.  How many of these bugs can be fixed without
> rewriting the dwarf2 reader?

Anything that is generic, and doesn't involve scoping, can be fixed
without rewriting the dwarf2 reader. In fact, rewriting the dwarf2
reader won't help them.

However, the dwarf2 reader was in bad need of a rewrite anyway.
It didn't even support all of dwarf2 properly, wasted tons of memory,
and couldn't possibly support dwarf2 if it tried, 
let alone be maintainable in the future.  It's a hacked up dwarf1
reader right now.

You speak of rewriting the dwarf2 reader as if it was a large body of
work that needed to be completed.
I'm about to submit it for approval in a few minutes.
In other words, it's pretty much done.
Bug fixes remain, i'm sure, but all functionality is now complete.
It qualifies names without relying on mangled names, properly manages
memory, can support all of dwarf2, and 2.1, etc.

>  My understanding is that both the
> virtual functions and the thunks bugs can.
Yup.

And the baseclass offset one can too.
But it's not particularly fun or easy to do.


Note that i only mention fixing the dwarf2 reader because you *can't*
fix the stabs reader, unless you introduce support for namespaces into
stabs, etc.
It's not worth the work.


> 
> 
> enjoy,
> 	Andrew
> 
> 

-- 
"I got a new shadow.  I had to get rid of the other one...  It
wasn't doing what I was doing.
"-Steven Wright

Re: So what is wrong with v3 C++

[Jim Blandy]

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.

Re: So what is wrong with v3 C++

[Daniel Berlin]

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

Re: So what is wrong with v3 C++

[Jim Blandy]

Daniel Berlin <dan@cgsoftware.com> writes:
> 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!

Can you post the GCC patches for generating namespace information
here?  That way, we can start working on GDB's support, and be ready
when GCC catches up.

(It seems to me that, if GCC is processing code that uses namespaces,
and generating mangled names and typeinfo objects that contain
prefixed names, but emitting Dwarf 2 information that has no record of
those prefixes, that should be called a GCC bug.  So it should be safe
to count on it getting fixed, whether or not using your patch.)

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

That does sound evil.

GDB has a tradition of accomodating broken debug info producers.  But
even when we can pin the problem on a specific version of the
compiler, those accomodations make the code harder to work with.  "If
I make this change, will it break our GCC 3.0 support?  I don't have
GCC 3.0 installed anywhere anymore..."

But until someone fixes stabs, I think it's reasonable to tell C++
users that GCC only provides sufficient information when using Dwarf
2.

Re: So what is wrong with v3 C++

[Daniel Berlin]

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Daniel Berlin <dan@cgsoftware.com> writes:
>> 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!
> 
> Can you post the GCC patches for generating namespace information
> here?  That way, we can start working on GDB's support, and be ready
> when GCC catches up.
Sure.
I'll just forward what i sent to gcc-patches.
I'll also post a new version of the new dwarf2 reader with namespace
support.


> 
> (It seems to me that, if GCC is processing code that uses namespaces,
> and generating mangled names and typeinfo objects that contain
> prefixed names, but emitting Dwarf 2 information that has no record of
> those prefixes, that should be called a GCC bug.  So it should be safe
> to count on it getting fixed, whether or not using your patch.)

Yes. The real problem we are running into, of course, is that types
themselves have no mangled names.
And if you fully qualified the name in the DW_AT_name attribute, you'd
run into all sorts of problems because DWARF2 really *can* support the
info we need, it just didn't output it. 
So it's an obviously broken thing, because we have 0 chance of getting
the info we need. it's simply not there.

> 
>> 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.
> 
> That does sound evil.
> 
> GDB has a tradition of accomodating broken debug info producers.  But
> even when we can pin the problem on a specific version of the
> compiler, those accomodations make the code harder to work with.  "If
> I make this change, will it break our GCC 3.0 support?  I don't have
> GCC 3.0 installed anywhere anymore..."
> 
> But until someone fixes stabs, I think it's reasonable to tell C++
> users that GCC only provides sufficient information when using Dwarf
> 2.

-- 
"I didn't get a toy train like the other kids.  I got a toy
subway instead.  You couldn't see anything, but every now and
then you'd hear this rumbling noise go by.
"-Steven Wright

Re: So what is wrong with v3 C++

[Jim Blandy]

Daniel Berlin <dan@cgsoftware.com> writes:
> Yes. The real problem we are running into, of course, is that types
> themselves have no mangled names.

Right, because they're not objects in memory.  They have no linker
symbol to name them, so we don't have anything to demangle and guess
the prefixes from.

> And if you fully qualified the name in the DW_AT_name attribute, you'd
> run into all sorts of problems because DWARF2 really *can* support the
> info we need, it just didn't output it. 

Doesn't Dwarf2 specify that it should be unqualified?  If it doesn't,
it should, it seems to me.


> So it's an obviously broken thing, because we have 0 chance of getting
> the info we need. it's simply not there.

Yep.

Re: So what is wrong with v3 C++

[Andrew Cagney]

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


My take would be, in order of priority:

	o	not dump core

	o	not lie when printing data

	o	anything else

you can work around broken step/next, it gets really hard to work around 
random core dumps and incorrect C++ output.

The second one is, I think, is somewhat unique to C++. Unlike more 
straight forward languages such as C, there is typically no 
direct/obvious correspondance between a data declaration and its 
representation in memory.  Consequently, it is important to get that 
data display right.

	Andrew