[RFC] Special casing dtors?

[RFC] Special casing dtors?

[Keith Seitz]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

Hi,

I've been looking a bit at a patch (in Fedora) which fixes prms/1112, 
and I notice that both valops.c and linespec.c treat destructors as 
"special case"s -- but nowhere does it say WHY.

I've searched through all the history I can find about this (including 
the Cygnus internal ueberbaum), and all I've been able to discover is 
that this has been in a LONG time (before 1990).

So out of curiosity, I removed all those special cases, and lo! There 
were no new failures, and one new pass in the testsuite (on x86, CVS HEAD).

Can anyone explain to me either why gdb treats dtors differently from 
"normal" methods or why we shouldn't commit something like the attached 
patch?

Keith

ChangeLog
2009-03-25  Keith Seitz  <keiths@redhat.com>

	* linespec.c (collect_methods): Delete.
	(add_matching_methods): Reove destructor special case.
	(find_method): Call find_methods directly instead of
	collect_methods.
	* valops.c (value_struct_elt): Remove destructor
	special cases.
	(check_field): Likewise.
	(value_struct_elt_for_reference): Likewise.
	(destructor_name_p): Remove misleading comment about dtors
	being "special cases".

[-- Attachment #2: dtor-special-case.patch --]
[-- Type: text/plain, Size: 4863 bytes --]

Index: linespec.c
===================================================================
RCS file: /cvs/src/src/gdb/linespec.c,v
retrieving revision 1.84
diff -u -p -r1.84 linespec.c
--- linespec.c	3 Jan 2009 05:57:52 -0000	1.84
+++ linespec.c	25 Mar 2009 22:28:08 -0000
@@ -76,10 +76,6 @@ static struct symtabs_and_lines find_met
 					     struct type *t,
 					     struct symbol *sym_class);
 
-static int collect_methods (char *copy, struct type *t,
-			    struct symbol *sym_class,
-			    struct symbol **sym_arr);
-
 static NORETURN void cplusplus_error (const char *name,
 				      const char *fmt, ...)
      ATTR_NORETURN ATTR_FORMAT (printf, 2, 3);
@@ -306,11 +302,6 @@ add_matching_methods (int method_counter
       else
 	phys_name = TYPE_FN_FIELD_PHYSNAME (f, field_counter);
 
-      /* Destructor is handled by caller, don't add it to
-	 the list.  */
-      if (is_destructor_name (phys_name) != 0)
-	continue;
-
       sym_arr[i1] = lookup_symbol_in_language (phys_name,
 				   NULL, VAR_DOMAIN,
 				   language,
@@ -1441,7 +1432,7 @@ find_method (int funfirstline, char ***c
   /* Find all methods with a matching name, and put them in
      sym_arr.  */
 
-  i1 = collect_methods (copy, t, sym_class, sym_arr);
+  i1 = find_methods (t, copy, SYMBOL_LANGUAGE (sym_class), sym_arr);
 
   if (i1 == 1)
     {
@@ -1492,37 +1483,6 @@ find_method (int funfirstline, char ***c
     }
 }
 
-/* Find all methods named COPY in the class whose type is T, and put
-   them in SYM_ARR.  Return the number of methods found.  */
-
-static int
-collect_methods (char *copy, struct type *t,
-		 struct symbol *sym_class, struct symbol **sym_arr)
-{
-  int i1 = 0;	/*  Counter for the symbol array.  */
-
-  if (destructor_name_p (copy, t))
-    {
-      /* Destructors are a special case.  */
-      int m_index, f_index;
-
-      if (get_destructor_fn_field (t, &m_index, &f_index))
-	{
-	  struct fn_field *f = TYPE_FN_FIELDLIST1 (t, m_index);
-
-	  sym_arr[i1] =
-	    lookup_symbol (TYPE_FN_FIELD_PHYSNAME (f, f_index),
-			   NULL, VAR_DOMAIN, (int *) NULL);
-	  if (sym_arr[i1])
-	    i1++;
-	}
-    }
-  else
-    i1 = find_methods (t, copy, SYMBOL_LANGUAGE (sym_class), sym_arr);
-
-  return i1;
-}
-
 \f
 
 /* Return the symtab associated to the filename given by the substring
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.210
diff -u -p -r1.210 valops.c
--- valops.c	20 Mar 2009 23:04:34 -0000	1.210
+++ valops.c	25 Mar 2009 22:28:09 -0000
@@ -1858,10 +1858,6 @@ value_struct_elt (struct value **argp, s
 
       /* C++: If it was not found as a data field, then try to
          return it as a pointer to a method.  */
-
-      if (destructor_name_p (name, t))
-	error (_("Cannot get value of destructor"));
-
       v = search_struct_method (name, argp, args, 0, 
 				static_memfuncp, t);
 
@@ -1877,32 +1873,6 @@ value_struct_elt (struct value **argp, s
       return v;
     }
 
-  if (destructor_name_p (name, t))
-    {
-      if (!args[1])
-	{
-	  /* Destructors are a special case.  */
-	  int m_index, f_index;
-
-	  v = NULL;
-	  if (get_destructor_fn_field (t, &m_index, &f_index))
-	    {
-	      v = value_fn_field (NULL, 
-				  TYPE_FN_FIELDLIST1 (t, m_index),
-				  f_index, NULL, 0);
-	    }
-	  if (v == NULL)
-	    error (_("could not find destructor function named %s."), 
-		   name);
-	  else
-	    return v;
-	}
-      else
-	{
-	  error (_("destructor should not have any argument"));
-	}
-    }
-  else
     v = search_struct_method (name, argp, args, 0, 
 			      static_memfuncp, t);
   
@@ -2508,8 +2478,6 @@ classify_oload_match (struct badness_vec
 int
 destructor_name_p (const char *name, const struct type *type)
 {
-  /* Destructors are a special case.  */
-
   if (name[0] == '~')
     {
       char *dname = type_name_no_tag (type);
@@ -2548,14 +2516,6 @@ check_field (struct type *type, const ch
   /* C++: If it was not found as a data field, then try to return it
      as a pointer to a method.  */
 
-  /* Destructors are a special case.  */
-  if (destructor_name_p (name, type))
-    {
-      int m_index, f_index;
-
-      return get_destructor_fn_field (type, &m_index, &f_index);
-    }
-
   for (i = TYPE_NFN_FIELDS (type) - 1; i >= 0; --i)
     {
       if (strcmp_iw (TYPE_FN_FIELDLIST_NAME (type, i), name) == 0)
@@ -2651,12 +2611,6 @@ value_struct_elt_for_reference (struct t
   /* C++: If it was not found as a data field, then try to return it
      as a pointer to a method.  */
 
-  /* Destructors are a special case.  */
-  if (destructor_name_p (name, t))
-    {
-      error (_("member pointers to destructors not implemented yet"));
-    }
-
   /* Perform all necessary dereferencing.  */
   while (intype && TYPE_CODE (intype) == TYPE_CODE_PTR)
     intype = TYPE_TARGET_TYPE (intype);

Re: [RFC] Special casing dtors?

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Keith> I've been looking a bit at a patch (in Fedora) which fixes
Keith> prms/1112, and I notice that both valops.c and linespec.c treat
Keith> destructors as "special case"s -- but nowhere does it say WHY.

Keith> I've searched through all the history I can find about this (including
Keith> the Cygnus internal ueberbaum), and all I've been able to discover is
Keith> that this has been in a LONG time (before 1990).

Keith> So out of curiosity, I removed all those special cases, and lo! There
Keith> were no new failures, and one new pass in the testsuite (on x86, CVS
Keith> HEAD).

Keith> Can anyone explain to me either why gdb treats dtors differently from
Keith> "normal" methods or why we shouldn't commit something like the
Keith> attached patch?

Given all the above, I would guess that removing this is the right
thing to do.  Anything that deletes code *and* improves the test
results can only be good :-)

Give it a few days; if nobody chimes in with a reason for this
mysterious special case, go ahead and check this in.

Tom

Re: [RFC] Special casing dtors?

[Stan Shebs]

Keith Seitz wrote:
> Hi,
>
> I've been looking a bit at a patch (in Fedora) which fixes prms/1112, 
> and I notice that both valops.c and linespec.c treat destructors as 
> "special case"s -- but nowhere does it say WHY.
>
> I've searched through all the history I can find about this (including 
> the Cygnus internal ueberbaum), and all I've been able to discover is 
> that this has been in a LONG time (before 1990).
1980s C++ was rather a different language from today, and G++ was even 
more different, so it could easily have been something that made sense 
for 1.x and not anything later.

Stan

Re: [RFC] Special casing dtors?

[Daniel Jacobowitz]

On Wed, Mar 25, 2009 at 03:33:29PM -0700, Keith Seitz wrote:
> Hi,
>
> I've been looking a bit at a patch (in Fedora) which fixes prms/1112, and 
> I notice that both valops.c and linespec.c treat destructors as "special 
> case"s -- but nowhere does it say WHY.
>
> I've searched through all the history I can find about this (including  
> the Cygnus internal ueberbaum), and all I've been able to discover is  
> that this has been in a LONG time (before 1990).
>
> So out of curiosity, I removed all those special cases, and lo! There  
> were no new failures, and one new pass in the testsuite (on x86, CVS 
> HEAD).
>
> Can anyone explain to me either why gdb treats dtors differently from  
> "normal" methods or why we shouldn't commit something like the attached  
> patch?

I remember, about five years ago, doing some serious surgery on the
way the stabs reader reported constructors and destructors.  If I had
to guess, I'd say this code was needed before that and/or for GCC 2.x.
But 2.x is pretty scarce on the ground nowadays anyway.  Either that,
or something for HP aCC.

Anyway, good riddance if your patch works!  What's the new PASS?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Special casing dtors?

[Keith Seitz]

Daniel Jacobowitz wrote:

> I remember, about five years ago, doing some serious surgery on the
> way the stabs reader reported constructors and destructors.  If I had
> to guess, I'd say this code was needed before that and/or for GCC 2.x.
> But 2.x is pretty scarce on the ground nowadays anyway.  Either that,
> or something for HP aCC.

Eeew... I didn't even think of other compilers and other debug formats. 
I will do what I can to test on some other platforms, but I hope some 
kind soul(s) out there will help me/us out by checking some environments 
to which I do not have access (anything non-GNU/Linux & cygwin). [Pretty 
please?]

> Anyway, good riddance if your patch works!  What's the new PASS?

It's "PASS: gdb.cp/templates.exp: destructor breakpoint". (Big surprise, 
no? Destructors just seem to work if they are not considered "special." :-)

Now, there might be ways to tickle something that this patch removes, 
but my belief is that we can always dig up the code out of CVS and 
reapply, this time with appropriate comments and test cases to explain 
WHY it is necessary.

Keith

PS. Tom Tromey pointed out to me that if this patch goes in, the 
function "get_destructor_fn_field" will become superfluous. I will, of 
course, submit a revised patch for that when/if the time comes.

Re: [RFC] Special casing dtors?

[Pedro Alves]

On Friday 27 March 2009 02:35:09, Keith Seitz wrote:
> > Anyway, good riddance if your patch works!  What's the new PASS?
> 
> It's "PASS: gdb.cp/templates.exp: destructor breakpoint". (Big surprise, 
> no? Destructors just seem to work if they are not considered "special." :-)
> 

I regtested the whole testsuite with stabs on x86_64-linux, and
got this with your patch:

 -PASS: gdb.cp/templates.exp: destructor breakpoint
 -PASS: gdb.cp/templates.exp: value method breakpoint
 +FAIL: gdb.cp/templates.exp: destructor_breakpoint (timeout)
 +FAIL: gdb.cp/templates.exp: value method breakpoint

 -# of expected passes           12895
 -# of unexpected failures       367
 +# of expected passes           12893
 +# of unexpected failures       369

You can try stabs with:

 make check RUNTESTFLAGS="--target_board=unix/gdb:debug_flags=-gstabs+ templates.exp"

-- 
Pedro Alves

Re: [RFC] Special casing dtors?

[Joel Brobecker]

> I regtested the whole testsuite with stabs on x86_64-linux, and
> got this with your patch:

Does stabs actually work on 64bit? I know there's been an extension
for Tru64, but how about GNU/Linux? On my machine, I get disastrous
results compared to 32bit Linux.

-- 
Joel

Re: [RFC] Special casing dtors?

[Keith Seitz]

Pedro Alves wrote:

> I regtested the whole testsuite with stabs on x86_64-linux, and
> got this with your patch:
> 
>  -PASS: gdb.cp/templates.exp: destructor breakpoint
>  -PASS: gdb.cp/templates.exp: value method breakpoint
>  +FAIL: gdb.cp/templates.exp: destructor_breakpoint (timeout)
>  +FAIL: gdb.cp/templates.exp: value method breakpoint

To be clear: You are getting two new FAILs with the patch? That would be 
baffling -- I don't see how the templates.exp test "destructor 
breakpoint" could pass on anything using gcc.

> You can try stabs with:
> 
>  make check RUNTESTFLAGS="--target_board=unix/gdb:debug_flags=-gstabs+ templates.exp"

I'll give this a shot. And thank you for checking out the patch.

Keith

Re: [RFC] Special casing dtors?

[Pedro Alves]

On Friday 27 March 2009 17:15:11, Keith Seitz wrote:
> Pedro Alves wrote:
> 
> > I regtested the whole testsuite with stabs on x86_64-linux, and
> > got this with your patch:
> > 
> >  -PASS: gdb.cp/templates.exp: destructor breakpoint
> >  -PASS: gdb.cp/templates.exp: value method breakpoint
> >  +FAIL: gdb.cp/templates.exp: destructor_breakpoint (timeout)
> >  +FAIL: gdb.cp/templates.exp: value method breakpoint
> 
> To be clear: You are getting two new FAILs with the patch? That would be 
> baffling -- I don't see how the templates.exp test "destructor 
> breakpoint" could pass on anything using gcc.

Yes, the patch causes the FAILs.  The test passes on
a pristine GDB.  Here's the relevant gdb.log diff:

 break T5<int>::~T5
-Breakpoint 2 at 0x804933d: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 478.
-(gdb) PASS: gdb.cp/templates.exp: destructor breakpoint
+[0] cancel
+[1] all
+[2] T5<int>::~T5() at ../../../src/gdb/testsuite/gdb.cp/templates.cc:478
+[3] T5<int>::~T5() at ../../../src/gdb/testsuite/gdb.cp/templates.cc:478
+> FAIL: gdb.cp/templates.exp: destructor_breakpoint (timeout)
 break T5<int>::value
-Breakpoint 3 at 0x8049359: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 493.
-(gdb) PASS: gdb.cp/templates.exp: value method breakpoint
+Arguments must be choice numbers.
+(gdb) FAIL: gdb.cp/templates.exp: value method breakpoint

Looks like GDB thinks there are two destructor instances in T5<int>.

I just confirmed this on x86-linux, to remove 64-bit out of
the picture.

-- 
Pedro Alves

Re: [RFC] Special casing dtors?

[Keith Seitz]

Pedro Alves wrote:

> I just confirmed this on x86-linux, to remove 64-bit out of
> the picture.

Okay, we have a problem. My machines show exactly the OPPOSITE behavior: 
templates.exp "destructor breakpoint" test KFAILs on both x86 and x86_64 
GNU/Linux. After the patch, this test PASSes on both machines. The other 
failure you had (templates.exp value method breakpoint) PASSes on both 
machines before and after the patch.

I can only guess that this has something to do with gcc... I'm using the 
F10 compiler, gcc version 4.3.2 20081105 (Red Hat 4.3.2-7).

Keith

Re: [RFC] Special casing dtors?

[Pedro Alves]

On Friday 27 March 2009 18:50:53, Keith Seitz wrote:
> Pedro Alves wrote:
> 
> > I just confirmed this on x86-linux, to remove 64-bit out of
> > the picture.
> 
> Okay, we have a problem. My machines show exactly the OPPOSITE behavior: 
> templates.exp "destructor breakpoint" test KFAILs on both x86 and x86_64 
> GNU/Linux. After the patch, this test PASSes on both machines. The other 
> failure you had (templates.exp value method breakpoint) PASSes on both 
> machines before and after the patch.

With stabs?  FSF GDB?  I *do* see that with dwarf.  I'll see if I
can try this on x86-cygwin, which is currently still using
gcc-3.4/stabs by default.

> I can only guess that this has something to do with gcc... I'm using the 
> F10 compiler, gcc version 4.3.2 20081105 (Red Hat 4.3.2-7).

I'm on ubuntu 8.04, gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3).

Actually, I didn't try x86, but "x86_64 -m32", but I don't think it
makes a difference in this case.

-- 
Pedro Alves

Re: [RFC] Special casing dtors?

[Keith Seitz]

Pedro Alves wrote:

> With stabs?  FSF GDB?  I *do* see that with dwarf.  I'll see if I
> can try this on x86-cygwin, which is currently still using
> gcc-3.4/stabs by default.

Yes, CVS HEAD last updated mid-day on March 25.

My last ChangeLog entry:

2009-03-25  Kevin Buettner  <kevinb@redhat.com>

	* mn10300-tdep.c (trad-frame.h): Don't include.
[snip]

I am building SVN gcc now, and I will retry everything.

BTW, I ran the testsuite on x86 and x86_64 w/stabs (again, using the F10 
compiler), and the summaries are absolutely identical (timestamp 
excepted): the patch has no effect.

Keith

Re: [RFC] Special casing dtors?

[Keith Seitz]

Keith Seitz wrote:

> I am building SVN gcc now, and I will retry everything.

I tried this with exactly the same result on both x86_64 and x86. [It 
took long enough!] The "destructor breakpoint" test FAILs without the 
patch, and the patch introduces no new failures. There must be something 
different about our environments.

I don't know what's going on now, but we seem to be at a "Mexican 
Stand-off? [Pardon the colloquialism]
Keith

Re: [RFC] Special casing dtors?

[Pedro Alves]

[-- Attachment #1: Type: text/plain, Size: 4660 bytes --]

On Saturday 28 March 2009 07:41:53, Keith Seitz wrote:
> Keith Seitz wrote:
> 
> > I am building SVN gcc now, and I will retry everything.
> 
> I tried this with exactly the same result on both x86_64 and x86. [It 
> took long enough!] The "destructor breakpoint" test FAILs without the 
> patch, and the patch introduces no new failures. There must be something 
> different about our environments.

No, it just means you went in the wrong direction with your
testing.  :-)

I mentioned that these tests pass on *4.2*, and that you see them
failing on 4.3.  It isn't much of a surprise that they fail on
gcc head.

I just tried the templates.exp test with both the top of the gcc 4.2
branch, and with current gcc head, both on stabs, x86_64.  Here's the
result difference:

--- gdb.sum.4.2	2009-03-30 16:50:48.000000000 +0100
+++ gdb.sum.4.5	2009-03-30 16:51:33.000000000 +0100
@@ -1,4 +1,4 @@
-Test Run By pedro on Mon Mar 30 16:50:39 2009
+Test Run By pedro on Mon Mar 30 16:51:25 2009
 Native configuration is x86_64-unknown-linux-gnu
 
 		=== gdb tests ===
@@ -9,38 +9,39 @@ Schedule of variations:
 Running target unix/gdb:debug_flags=-gstabs+
 Running ../../../src/gdb/testsuite/gdb.cp/templates.exp ...
 PASS: gdb.cp/templates.exp: set multiple-symbols ask
-PASS: gdb.cp/templates.exp: ptype T5<int> (obsolescent gcc or gdb)
-PASS: gdb.cp/templates.exp: ptype t5i (obsolescent gcc or gdb)
-FAIL: gdb.cp/templates.exp: constructor breakpoint (bad menu choices)
+FAIL: gdb.cp/templates.exp: ptype T5<int>
+FAIL: gdb.cp/templates.exp: ptype t5i
+FAIL: gdb.cp/templates.exp: constructor breakpoint
 PASS: gdb.cp/templates.exp: destructor breakpoint
 PASS: gdb.cp/templates.exp: value method breakpoint
 PASS: gdb.cp/templates.exp: print t5i.value()
 PASS: gdb.cp/templates.exp: print fint
 PASS: gdb.cp/templates.exp: print fvpchar
-PASS: gdb.cp/templates.exp: ptype Foo
-PASS: gdb.cp/templates.exp: ptype fint
-PASS: gdb.cp/templates.exp: ptype fchar
-PASS: gdb.cp/templates.exp: ptype fvpchar
-PASS: gdb.cp/templates.exp: print Foo<volatile char *>::foo
-PASS: gdb.cp/templates.exp: print Foo<volatile char*>::foo
-PASS: gdb.cp/templates.exp: ptype Bar
-PASS: gdb.cp/templates.exp: ptype bint
-PASS: gdb.cp/templates.exp: ptype bint2
-PASS: gdb.cp/templates.exp: ptype Baz
-PASS: gdb.cp/templates.exp: ptype bazint
-PASS: gdb.cp/templates.exp: ptype bazint2
-PASS: gdb.cp/templates.exp: ptype Qux
-PASS: gdb.cp/templates.exp: ptype quxint
-PASS: gdb.cp/templates.exp: ptype Spec
-PASS: gdb.cp/templates.exp: ptype siip
-PASS: gdb.cp/templates.exp: ptype Garply<int>
-PASS: gdb.cp/templates.exp: ptype Garply<Garply<char> >
-PASS: gdb.cp/templates.exp: print Garply<Garply<char> >::garply
+FAIL: gdb.cp/templates.exp: ptype Foo
+FAIL: gdb.cp/templates.exp: ptype fint
+FAIL: gdb.cp/templates.exp: ptype fchar
+FAIL: gdb.cp/templates.exp: ptype fvpchar
+KFAIL: gdb.cp/templates.exp: print Foo<volatile char *>::foo (PRMS: gdb/931)
+KFAIL: gdb.cp/templates.exp: print Foo<volatile char*>::foo (PRMS: gdb/931)
+FAIL: gdb.cp/templates.exp: ptype Bar
+FAIL: gdb.cp/templates.exp: ptype bint
+FAIL: gdb.cp/templates.exp: ptype bint2
+FAIL: gdb.cp/templates.exp: ptype Baz
+FAIL: gdb.cp/templates.exp: ptype bazint
+FAIL: gdb.cp/templates.exp: ptype bazint2
+FAIL: gdb.cp/templates.exp: ptype Qux
+FAIL: gdb.cp/templates.exp: ptype quxint
+FAIL: gdb.cp/templates.exp: ptype Spec
+FAIL: gdb.cp/templates.exp: ptype siip
+FAIL: gdb.cp/templates.exp: ptype Garply<int>
+FAIL: gdb.cp/templates.exp: ptype Garply<Garply<char> >
+FAIL: gdb.cp/templates.exp: print Garply<Garply<char> >::garply
 PASS: gdb.cp/templates.exp: break Garply<Garply<char> >::garply
 
 		=== gdb Summary ===
 
-# of expected passes		28
-# of unexpected failures	1
+# of expected passes		7
+# of unexpected failures	20
+# of known failures		2
 /home/pedro/gdb/baseline/build/gdb/testsuite/../../gdb/gdb version  6.8.50.20090327-cvs -nw -nx 
 
So, gcc regressed a bunch of stabs after gcc 4.2.  The full logs of running
this test with both compilers are attached.

> 
> I don't know what's going on now, but we seem to be at a "Mexican 
> Stand-off? [Pardon the colloquialism]

I don't know how much we care for stabs on 4.2.  Certainly on
linux it isn't that important, but other platforms are still a
bit stuck with it.  Note that I'm not objecting to you applying
your patch.  The failure mode it introduces on stabs isn't that
critical.  I was merely trying to be helpful, and I didn't
expect that we'd find this.  In any case, it is always good to
try out several compilers, not just the tip of the trunk.  GDB
has to cope with code produced from older compilers as well.

-- 
Pedro Alves

[-- Attachment #2: gdb.sum.4.2 --]
[-- Type: text/plain, Size: 1840 bytes --]

Test Run By pedro on Mon Mar 30 16:50:39 2009
Native configuration is x86_64-unknown-linux-gnu

		=== gdb tests ===

Schedule of variations:
    unix/gdb:debug_flags=-gstabs+

Running target unix/gdb:debug_flags=-gstabs+
Running ../../../src/gdb/testsuite/gdb.cp/templates.exp ...
PASS: gdb.cp/templates.exp: set multiple-symbols ask
PASS: gdb.cp/templates.exp: ptype T5<int> (obsolescent gcc or gdb)
PASS: gdb.cp/templates.exp: ptype t5i (obsolescent gcc or gdb)
FAIL: gdb.cp/templates.exp: constructor breakpoint (bad menu choices)
PASS: gdb.cp/templates.exp: destructor breakpoint
PASS: gdb.cp/templates.exp: value method breakpoint
PASS: gdb.cp/templates.exp: print t5i.value()
PASS: gdb.cp/templates.exp: print fint
PASS: gdb.cp/templates.exp: print fvpchar
PASS: gdb.cp/templates.exp: ptype Foo
PASS: gdb.cp/templates.exp: ptype fint
PASS: gdb.cp/templates.exp: ptype fchar
PASS: gdb.cp/templates.exp: ptype fvpchar
PASS: gdb.cp/templates.exp: print Foo<volatile char *>::foo
PASS: gdb.cp/templates.exp: print Foo<volatile char*>::foo
PASS: gdb.cp/templates.exp: ptype Bar
PASS: gdb.cp/templates.exp: ptype bint
PASS: gdb.cp/templates.exp: ptype bint2
PASS: gdb.cp/templates.exp: ptype Baz
PASS: gdb.cp/templates.exp: ptype bazint
PASS: gdb.cp/templates.exp: ptype bazint2
PASS: gdb.cp/templates.exp: ptype Qux
PASS: gdb.cp/templates.exp: ptype quxint
PASS: gdb.cp/templates.exp: ptype Spec
PASS: gdb.cp/templates.exp: ptype siip
PASS: gdb.cp/templates.exp: ptype Garply<int>
PASS: gdb.cp/templates.exp: ptype Garply<Garply<char> >
PASS: gdb.cp/templates.exp: print Garply<Garply<char> >::garply
PASS: gdb.cp/templates.exp: break Garply<Garply<char> >::garply

		=== gdb Summary ===

# of expected passes		28
# of unexpected failures	1
/home/pedro/gdb/baseline/build/gdb/testsuite/../../gdb/gdb version  6.8.50.20090327-cvs -nw -nx 


[-- Attachment #3: gdb.log.4.2 --]
[-- Type: text/x-java, Size: 8711 bytes --]

Test Run By pedro on Mon Mar 30 16:50:39 2009
Native configuration is x86_64-unknown-linux-gnu

		=== gdb tests ===

Schedule of variations:
    unix/gdb:debug_flags=-gstabs+

Running target unix/gdb:debug_flags=-gstabs+
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../src/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file.
Running ../../../src/gdb/testsuite/gdb.cp/templates.exp ...
get_compiler_info: gcc-4-2-5
Executing on host: g++ ../../../src/gdb/testsuite/gdb.cp/templates.cc   -L/home/pedro/gdb/baseline/build/libiberty  -gstabs+  -lm   -o /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates    (timeout = 300)
GNU gdb (GDB) 6.8.50.20090327-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set height 0
(gdb) set width 0
(gdb) dir
Reinitialize source path to empty? (y or n) y
Source directories searched: $cdir:$cwd
(gdb) dir ../../../src/gdb/testsuite/gdb.cp
Source directories searched: /home/pedro/gdb/baseline/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.cp:$cdir:$cwd
(gdb) kill
The program is not being run.
(gdb) file /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates
Reading symbols from /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates...done.
(gdb) set multiple-symbols ask
(gdb) PASS: gdb.cp/templates.exp: set multiple-symbols ask
delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x4012d4: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 713.
(gdb) run 
Starting program: /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates 

Breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.cp/templates.cc:713
713	    i = i + 1;
(gdb) ptype T5<int>
type = class T5<int> {
  public:
    static int X;
    int x;
    int val;

    T5(int);
    T5(int);
    T5(T5<int> const&);
    T5(T5<int> const&);
    ~T5();
    ~T5();
    static void * operator new(unsigned long);
    static void operator delete(void*);
    int value();
}
(gdb) PASS: gdb.cp/templates.exp: ptype T5<int> (obsolescent gcc or gdb)
ptype t5i
type = class T5<int> {
  public:
    static int X;
    int x;
    int val;

    T5(int);
    T5(int);
    T5(T5<int> const&);
    T5(T5<int> const&);
    ~T5();
    ~T5();
    static void * operator new(unsigned long);
    static void operator delete(void*);
    int value();
}
(gdb) PASS: gdb.cp/templates.exp: ptype t5i (obsolescent gcc or gdb)
break T5<int>::T5
[0] cancel
[1] all
[2] T5<int>::T5(T5<int> const&) at ../../../src/gdb/testsuite/gdb.cp/templates.cc:474
[3] T5<int>::T5(T5<int> const&) at ../../../src/gdb/testsuite/gdb.cp/templates.cc:474
[4] T5<int>::T5(int) at ../../../src/gdb/testsuite/gdb.cp/templates.cc:470
[5] T5<int>::T5(int) at ../../../src/gdb/testsuite/gdb.cp/templates.cc:470
> 0
canceled
(gdb) FAIL: gdb.cp/templates.exp: constructor breakpoint (bad menu choices)
break T5<int>::~T5
Breakpoint 2 at 0x4017aa: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 478.
(gdb) PASS: gdb.cp/templates.exp: destructor breakpoint
break T5<int>::value
Breakpoint 3 at 0x4017d8: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 493.
(gdb) PASS: gdb.cp/templates.exp: value method breakpoint
delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 4 at 0x4012d4: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 713.
(gdb) run 
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates 

Breakpoint 4, main () at ../../../src/gdb/testsuite/gdb.cp/templates.cc:713
713	    i = i + 1;
(gdb) print t5i.value()
$1 = 2
(gdb) PASS: gdb.cp/templates.exp: print t5i.value()
b 770
Breakpoint 5 at 0x4014a2: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 770.
(gdb) c
Continuing.

Breakpoint 5, main () at ../../../src/gdb/testsuite/gdb.cp/templates.cc:770
770	  return 0;
(gdb) print fint
$2 = {x = 0, t = 0}
(gdb) PASS: gdb.cp/templates.exp: print fint
print fvpchar
$3 = {x = 0, t = 0x0}
(gdb) PASS: gdb.cp/templates.exp: print fvpchar
ptype Foo
No symbol "Foo" in current context.
(gdb) PASS: gdb.cp/templates.exp: ptype Foo
ptype fint
type = class Foo<int> {
  public:
    int x;
    int t;

    int foo(int, int);
}
(gdb) PASS: gdb.cp/templates.exp: ptype fint
ptype fchar
type = class Foo<char> {
  public:
    int x;
    char t;

    char foo(int, char);
}
(gdb) PASS: gdb.cp/templates.exp: ptype fchar
ptype fvpchar
type = class Foo<volatile char*> {
  public:
    int x;
    volatile char *t;

    volatile char * foo(int, char volatile*);
}
(gdb) PASS: gdb.cp/templates.exp: ptype fvpchar
print Foo<volatile char *>::foo
$4 = {volatile char *(Foo<volatile char*> * const, int, volatile char *)} 0x40191e <Foo<char volatile*>::foo(int, char volatile*)>
(gdb) PASS: gdb.cp/templates.exp: print Foo<volatile char *>::foo
print Foo<volatile char*>::foo
$5 = {volatile char *(Foo<volatile char*> * const, int, volatile char *)} 0x40191e <Foo<char volatile*>::foo(int, char volatile*)>
(gdb) PASS: gdb.cp/templates.exp: print Foo<volatile char*>::foo
ptype Bar
No symbol "Bar" in current context.
(gdb) PASS: gdb.cp/templates.exp: ptype Bar
ptype bint
type = class Bar<int,33> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) PASS: gdb.cp/templates.exp: ptype bint
ptype bint2
type = class Bar<int,1> {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) PASS: gdb.cp/templates.exp: ptype bint2
ptype Baz
No symbol "Baz" in current context.
(gdb) PASS: gdb.cp/templates.exp: ptype Baz
ptype bazint
type = class Baz<int,'s'> {
  public:
    int x;
    int t;

    int baz(int, int);
}
(gdb) PASS: gdb.cp/templates.exp: ptype bazint
ptype bazint2
type = class Baz<char,'a'> {
  public:
    int x;
    char t;

    char baz(int, char);
}
(gdb) PASS: gdb.cp/templates.exp: ptype bazint2
ptype Qux
No symbol "Qux" in current context.
(gdb) PASS: gdb.cp/templates.exp: ptype Qux
ptype quxint
type = class Qux<int,(char*)(& string)> {
  public:
    int x;
    int t;

    int qux(int, int);
}
(gdb) PASS: gdb.cp/templates.exp: ptype quxint
ptype Spec
No symbol "Spec" in current context.
(gdb) PASS: gdb.cp/templates.exp: ptype Spec
ptype siip
type = class Spec<int,int*> {
  public:
    int x;

    int spec(int*);
}
(gdb) PASS: gdb.cp/templates.exp: ptype siip
ptype Garply<int>
type = class Garply<int> {
  public:
    int x;
    int t;

    int garply(int, int);
}
(gdb) PASS: gdb.cp/templates.exp: ptype Garply<int>
ptype Garply<Garply<char> >
type = class Garply<Garply<char> > {
  public:
    int x;
    Garply<char> t;

    Garply<char> garply(int, Garply<char>);
}
(gdb) PASS: gdb.cp/templates.exp: ptype Garply<Garply<char> >
print Garply<Garply<char> >::garply
$6 = {Garply<char> (Garply<Garply<char> > * const, int, Garply<char>)} 0x401abc <Garply<Garply<char> >::garply(int, Garply<char>)>
(gdb) PASS: gdb.cp/templates.exp: print Garply<Garply<char> >::garply
break Garply<Garply<char> >::garply
Breakpoint 6 at 0x401acb: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 696.
(gdb) PASS: gdb.cp/templates.exp: break Garply<Garply<char> >::garply
testcase ../../../src/gdb/testsuite/gdb.cp/templates.exp completed in 2 seconds

		=== gdb Summary ===

# of expected passes		28
# of unexpected failures	1
Executing on host: /home/pedro/gdb/baseline/build/gdb/testsuite/../../gdb/gdb -nw -nx --command gdb_cmd    (timeout = 300)
GNU gdb (GDB) 6.8.50.20090327-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
/home/pedro/gdb/baseline/build/gdb/testsuite/../../gdb/gdb version  6.8.50.20090327-cvs -nw -nx 

runtest completed at Mon Mar 30 16:50:41 2009

[-- Attachment #4: gdb.sum.4.5 --]
[-- Type: text/plain, Size: 1828 bytes --]

Test Run By pedro on Mon Mar 30 16:51:25 2009
Native configuration is x86_64-unknown-linux-gnu

		=== gdb tests ===

Schedule of variations:
    unix/gdb:debug_flags=-gstabs+

Running target unix/gdb:debug_flags=-gstabs+
Running ../../../src/gdb/testsuite/gdb.cp/templates.exp ...
PASS: gdb.cp/templates.exp: set multiple-symbols ask
FAIL: gdb.cp/templates.exp: ptype T5<int>
FAIL: gdb.cp/templates.exp: ptype t5i
FAIL: gdb.cp/templates.exp: constructor breakpoint
PASS: gdb.cp/templates.exp: destructor breakpoint
PASS: gdb.cp/templates.exp: value method breakpoint
PASS: gdb.cp/templates.exp: print t5i.value()
PASS: gdb.cp/templates.exp: print fint
PASS: gdb.cp/templates.exp: print fvpchar
FAIL: gdb.cp/templates.exp: ptype Foo
FAIL: gdb.cp/templates.exp: ptype fint
FAIL: gdb.cp/templates.exp: ptype fchar
FAIL: gdb.cp/templates.exp: ptype fvpchar
KFAIL: gdb.cp/templates.exp: print Foo<volatile char *>::foo (PRMS: gdb/931)
KFAIL: gdb.cp/templates.exp: print Foo<volatile char*>::foo (PRMS: gdb/931)
FAIL: gdb.cp/templates.exp: ptype Bar
FAIL: gdb.cp/templates.exp: ptype bint
FAIL: gdb.cp/templates.exp: ptype bint2
FAIL: gdb.cp/templates.exp: ptype Baz
FAIL: gdb.cp/templates.exp: ptype bazint
FAIL: gdb.cp/templates.exp: ptype bazint2
FAIL: gdb.cp/templates.exp: ptype Qux
FAIL: gdb.cp/templates.exp: ptype quxint
FAIL: gdb.cp/templates.exp: ptype Spec
FAIL: gdb.cp/templates.exp: ptype siip
FAIL: gdb.cp/templates.exp: ptype Garply<int>
FAIL: gdb.cp/templates.exp: ptype Garply<Garply<char> >
FAIL: gdb.cp/templates.exp: print Garply<Garply<char> >::garply
PASS: gdb.cp/templates.exp: break Garply<Garply<char> >::garply

		=== gdb Summary ===

# of expected passes		7
# of unexpected failures	20
# of known failures		2
/home/pedro/gdb/baseline/build/gdb/testsuite/../../gdb/gdb version  6.8.50.20090327-cvs -nw -nx 


[-- Attachment #5: gdb.log.4.5 --]
[-- Type: text/x-objcsrc, Size: 7942 bytes --]

Test Run By pedro on Mon Mar 30 16:51:25 2009
Native configuration is x86_64-unknown-linux-gnu

		=== gdb tests ===

Schedule of variations:
    unix/gdb:debug_flags=-gstabs+

Running target unix/gdb:debug_flags=-gstabs+
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../src/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file.
Running ../../../src/gdb/testsuite/gdb.cp/templates.exp ...
get_compiler_info: gcc-4-5-0
Executing on host: g++ ../../../src/gdb/testsuite/gdb.cp/templates.cc   -L/home/pedro/gdb/baseline/build/libiberty  -gstabs+  -lm   -o /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates    (timeout = 300)
GNU gdb (GDB) 6.8.50.20090327-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set height 0
(gdb) set width 0
(gdb) dir
Reinitialize source path to empty? (y or n) y
Source directories searched: $cdir:$cwd
(gdb) dir ../../../src/gdb/testsuite/gdb.cp
Source directories searched: /home/pedro/gdb/baseline/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.cp:$cdir:$cwd
(gdb) kill
The program is not being run.
(gdb) file /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates
Reading symbols from /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates...done.
(gdb) set multiple-symbols ask
(gdb) PASS: gdb.cp/templates.exp: set multiple-symbols ask
delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x401335: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 713.
(gdb) run 
Starting program: /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates 

Breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.cp/templates.cc:713
713	    i = i + 1;
(gdb) ptype T5<int>
No symbol "T5<int>" in current context.
(gdb) FAIL: gdb.cp/templates.exp: ptype T5<int>
ptype t5i
type = class T5 {
  public:
    static int X;
    int x;
    int val;

    T5(int);
    T5(int);
    T5(T5<int> const&);
    T5(T5<int> const&);
    ~T5();
    ~T5();
    static void * operator new(unsigned long);
    static void operator delete(void*);
    int value();
}
(gdb) FAIL: gdb.cp/templates.exp: ptype t5i
break T5<int>::T5
Breakpoint 2 at 0x40169d: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 470.
(gdb) FAIL: gdb.cp/templates.exp: constructor breakpoint
break T5<int>::~T5
Breakpoint 3 at 0x4017d2: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 478.
(gdb) PASS: gdb.cp/templates.exp: destructor breakpoint
break T5<int>::value
Breakpoint 4 at 0x401800: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 493.
(gdb) PASS: gdb.cp/templates.exp: value method breakpoint
delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 5 at 0x401335: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 713.
(gdb) run 
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.cp/templates 

Breakpoint 5, main () at ../../../src/gdb/testsuite/gdb.cp/templates.cc:713
713	    i = i + 1;
(gdb) print t5i.value()
$1 = 2
(gdb) PASS: gdb.cp/templates.exp: print t5i.value()
b 770
Breakpoint 6 at 0x401534: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 770.
(gdb) c
Continuing.

Breakpoint 6, main () at ../../../src/gdb/testsuite/gdb.cp/templates.cc:770
770	  return 0;
(gdb) print fint
$2 = {x = 0, t = 0}
(gdb) PASS: gdb.cp/templates.exp: print fint
print fvpchar
$3 = {x = 0, t = 0x0}
(gdb) PASS: gdb.cp/templates.exp: print fvpchar
ptype Foo
type = class Foo {
  public:
    int x;
    int t;

    int foo(int, int);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype Foo
ptype fint
type = class Foo {
  public:
    int x;
    int t;

    int foo(int, int);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype fint
ptype fchar
type = class Foo {
  public:
    int x;
    char t;

    char foo(int, char);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype fchar
ptype fvpchar
type = class Foo {
  public:
    int x;
    volatile char *t;

    volatile char * foo(int, char volatile*);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype fvpchar
print Foo<volatile char *>::foo
No symbol "Foo<volatile char *>" in current context.
(gdb) KFAIL: gdb.cp/templates.exp: print Foo<volatile char *>::foo (PRMS: gdb/931)
print Foo<volatile char*>::foo
No symbol "Foo<volatile char*>" in current context.
(gdb) KFAIL: gdb.cp/templates.exp: print Foo<volatile char*>::foo (PRMS: gdb/931)
ptype Bar
type = class Bar {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype Bar
ptype bint
type = class Bar {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype bint
ptype bint2
type = class Bar {
  public:
    int x;
    int t;

    int bar(int, int);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype bint2
ptype Baz
type = class Baz {
  public:
    int x;
    int t;

    int baz(int, int);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype Baz
ptype bazint
type = class Baz {
  public:
    int x;
    int t;

    int baz(int, int);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype bazint
ptype bazint2
type = class Baz {
  public:
    int x;
    char t;

    char baz(int, char);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype bazint2
ptype Qux
type = class Qux {
  public:
    int x;
    char t;

    char qux(int, char);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype Qux
ptype quxint
type = class Qux {
  public:
    int x;
    int t;

    int qux(int, int);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype quxint
ptype Spec
type = class Spec {
  public:
    int x;

    int spec(char);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype Spec
ptype siip
type = class Spec {
  public:
    int x;

    int spec(int*);
}
(gdb) FAIL: gdb.cp/templates.exp: ptype siip
ptype Garply<int>
No symbol "Garply<int>" in current context.
(gdb) FAIL: gdb.cp/templates.exp: ptype Garply<int>
ptype Garply<Garply<char> >
No symbol "Garply<Garply<char> >" in current context.
(gdb) FAIL: gdb.cp/templates.exp: ptype Garply<Garply<char> >
print Garply<Garply<char> >::garply
No symbol "Garply<Garply<char> >" in current context.
(gdb) FAIL: gdb.cp/templates.exp: print Garply<Garply<char> >::garply
break Garply<Garply<char> >::garply
Breakpoint 7 at 0x401abd: file ../../../src/gdb/testsuite/gdb.cp/templates.cc, line 696.
(gdb) PASS: gdb.cp/templates.exp: break Garply<Garply<char> >::garply
testcase ../../../src/gdb/testsuite/gdb.cp/templates.exp completed in 2 seconds

		=== gdb Summary ===

# of expected passes		7
# of unexpected failures	20
# of known failures		2
Executing on host: /home/pedro/gdb/baseline/build/gdb/testsuite/../../gdb/gdb -nw -nx --command gdb_cmd    (timeout = 300)
GNU gdb (GDB) 6.8.50.20090327-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
/home/pedro/gdb/baseline/build/gdb/testsuite/../../gdb/gdb version  6.8.50.20090327-cvs -nw -nx 

runtest completed at Mon Mar 30 16:51:27 2009

Re: [RFC] Special casing dtors?

[Keith Seitz]

[-- Attachment #1: Type: text/plain, Size: 4674 bytes --]

I apologize ahead of time for the lengthy treatise here... I am not 
trying to be argumentative or anything, I just want to explain as best 
and fully as I can what I've discovered. Thank you to anyone that 
actually reads all of this. :-)

Pedro Alves wrote:

> I mentioned that these tests pass on *4.2*, and that you see them
> failing on 4.3.  It isn't much of a surprise that they fail on
> gcc head.

Actually, they PASS on gcc HEAD, too. At least, they did here. O:-)

> I just tried the templates.exp test with both the top of the gcc 4.2
> branch, and with current gcc head, both on stabs, x86_64.  Here's the
> result difference:
[big snip]

I have run with gcc 4.2.0, 4.2.4, and gcc 4.3.2 releases (well, F10 
w/4.3.2), and I was finally able to reproduce the failures you mention 
with -gstabs+ (on the 4.2.x compilers). After digging into this for 
quite some time, I am convinced this happens not because of my patch, 
but because stabs is just really broken in gdb.

For example:
Consider the much simpler case of setting a breakpoint on a ctor/dtor 
(non-template) -- for which there is not ONE single test in gdb's testsuite:

$ cat simple.cc
#include <iostream>

using namespace std;

class aclass
{
  public:
    aclass (void) { cout << "ctor" << endl; };
    ~aclass (void) { cout << "dtor" << endl; };
};

int
main (int argc, char *argv[])
{
   aclass* ac = new aclass();
   delete ac;
   return 0;
}

Compile this with gcc-4.2.4 with -gstabs+ (or DWARF, it doesn't matter) 
and run this under FSF gdb CVS HEAD (from a few days ago) :

(gdb) break aclass::~aclass
the class `aclass' does not have destructor defined
Hint: try 'aclass::~aclass<TAB> or 'aclass::~aclass<ESC-?>
(Note leading single quote.)

Run this under my proposed patch:
(gdb) break aclass::~aclass
Breakpoint 1 at 0x80489fe: file simple.cc, line 9.

[Anecdote: With the templates.exp dtor test, while gdb is able to set a 
breakpoint, it never actually hits it. At all. It does with my patch.]

So clearly, things are as complicated as we've discovered. The actual 
templates.exp tests which are/are not failing are template ctor and dtor 
tests -- ones I could also not reduce to simpler test cases. So I had a 
look specifically at templates.cc -- it has been over a decade since I 
looked at stabs output! -- and I discovered that the stabs info DOES 
define TWO ctors and TWO dtors.

So I stepped the patched and unpatched gdbs side-by-side until I found 
something different. While I claim neither to understand everything 
behind this nor why fixing the difference I did find caused such a 
massive positive change in test results, it is clear that something 
changed in gcc somewhere, and the corresponding change never got to gdb.

I've attached a secondary patch for stabsread.c which not only fixes the 
failing tests you found (with -gstabs+), but also fixes tons of other 
failures in classes.exp and virtfunc.exp (and more). Again, don't ask me 
why. The fix seems innocently isolated enough, but it just reduces the 
number of failed tests from >400 to just over 300.

Can you apply the attached patch to your tree and try again?

> I don't know how much we care for stabs on 4.2.  Certainly on
> linux it isn't that important, but other platforms are still a
> bit stuck with it.  Note that I'm not objecting to you applying
> your patch.  The failure mode it introduces on stabs isn't that
> critical.

I think that what is simply happening here is that there is some severe 
stabs breakage in gdb (and no one noticed/tested/complained?). It just 
so happens that some of these failures were being hidden by what I 
suspect is very old code. By removing the old code, the (or a) real 
problem was exposed. I have no doubt that there are many more 
undiscovered bugs w.r.t. C++ and stabs.

> I was merely trying to be helpful, and I didn't
> expect that we'd find this.  In any case, it is always good to
> try out several compilers, not just the tip of the trunk.  GDB
> has to cope with code produced from older compilers as well.

I certainly understand (and appreciate) that you are trying to be 
helpful -- and you are! I never felt otherwise.

So, I guess my position is that since stabs is so darn broken any way, 
we might as well apply the patch and deal with the fallout. At least 
then we'll know (and hopefully document) WHY all this special casing of 
dtors is necessary.

Keith

PS. I still don't understand how you are getting DWARF2 failures. I've 
run these tests on gcc 4.2.0, 4.2.4, 4.3.2, and 4.4.0, and NONE of those 
compilers demonstrate any failures after the patch; they all fail BEFORE 
the patch is applied. I guess I'll deal with this next.

[-- Attachment #2: ignore-__base_dtor-ctor.patch --]
[-- Type: text/plain, Size: 745 bytes --]

Index: stabsread.c
===================================================================
RCS file: /cvs/src/src/gdb/stabsread.c,v
retrieving revision 1.113
diff -u -p -r1.113 stabsread.c
--- stabsread.c	21 Feb 2009 16:14:49 -0000	1.113
+++ stabsread.c	1 Apr 2009 23:03:22 -0000
@@ -2408,8 +2408,8 @@ read_member_functions (struct field_info
 
       /* Skip GCC 3.X member functions which are duplicates of the callable
 	 constructor/destructor.  */
-      if (strcmp (main_fn_name, "__base_ctor") == 0
-	  || strcmp (main_fn_name, "__base_dtor") == 0
+      if (strcmp_iw (main_fn_name, "__base_ctor ") == 0
+	  || strcmp_iw (main_fn_name, "__base_dtor ") == 0
 	  || strcmp (main_fn_name, "__deleting_dtor") == 0)
 	{
 	  xfree (main_fn_name);

Re: [RFC] Special casing dtors?

[Daniel Jacobowitz]

On Wed, Apr 01, 2009 at 04:46:17PM -0700, Keith Seitz wrote:
> I've attached a secondary patch for stabsread.c which not only fixes the  
> failing tests you found (with -gstabs+), but also fixes tons of other  
> failures in classes.exp and virtfunc.exp (and more). Again, don't ask me  
> why. The fix seems innocently isolated enough, but it just reduces the  
> number of failed tests from >400 to just over 300.

I don't understand the patch - would you mind posting affected stabs
from 4.2 and HEAD?  Sounds like GCC made the incompatible change here,
not GDB.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Special casing dtors?

[Keith Seitz]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

Daniel Jacobowitz wrote:
> On Wed, Apr 01, 2009 at 04:46:17PM -0700, Keith Seitz wrote:

> I don't understand the patch - would you mind posting affected stabs
> from 4.2 and HEAD?  Sounds like GCC made the incompatible change here,
> not GDB.

Stabs attached.

Gcc did make the change, but as Pedro pointed out in a previous note, 
"GDB has to cope with code produced from older compilers as well." Since 
4.2.0 and 4.2.4 are long out the door, I was simply attempting to 
accommodating.

Keith

[-- Attachment #2: affected-stabs.txt --]
[-- Type: text/plain, Size: 1291 bytes --]

gcc 4.2.4:

40     LSYM   0      454    00000000 4211   T5<int>:Tt(0,62)=s8X:/2(0,7):_ZN2T5IiE1XE;x:(0,7),0,32;val:(0,7),32,32;__base_ctor ::(0,63)=#(0,62),(0,20),(0,64)=*(0,62),(0,7),(0,20);:_ZN2T5IiEC2Ei;2A.;__comp_ctor ::(0,63):_ZN2T5IiEC1Ei;2A.;__base_ctor ::(0,65)=#(0,62),(0,20),(0,64),(0,66)=&(0,67)=k(0,62),(0,20);:_ZN2T5IiEC2ERKS0_;2A.;__comp_ctor ::(0,65):_ZN2T5IiEC1ERKS0_;2A.;__base_dtor ::(0,68)=#(0,62),(0,20),(0,64),(0,20);:_ZN2T5IiED2Ev;2A.;__comp_dtor ::(0,68):_ZN2T5IiED1Ev;2A.;operator new::(0,60):_ZN2T5IiEnwEj;2A?;operator delete::(0,37):_ZN2T5IiEdlEPv;2A?;value::(0,69)=#(0,62),(0,7),(0,64),(0,20);:_ZN2T5IiE5valueEv;2A.;;


gcc HEAD:

40     LSYM   0      454    00000000 3650
T5:Tt(0,54)=s8X:/2(0,4):_ZN2T5IcE1XE;x:(0,4),0,8;val:(0,9),32,32;__base_ctor ::(0,55)=#(0,54),(0,21),(0,56)=*(0,54),(0,9),(0,21);:_ZN2T5IcEC2Ei;2A.;__comp_ctor ::(0,55):_ZN2T5IcEC1Ei;2A.;__base_ctor ::(0,57)=#(0,54),(0,21),(0,56),(0,58)=&(0,59)=k(0,54),(0,21);:_ZN2T5IcEC2ERKS0_;2A.;__comp_ctor ::(0,57):_ZN2T5IcEC1ERKS0_;2A.;__base_dtor ::(0,60)=#(0,54),(0,21),(0,56),(0,21);:_ZN2T5IcED2Ev;2A.;__comp_dtor ::(0,60):_ZN2T5IcED1Ev;2A.;operator new::(0,61)=f(0,29):_ZN2T5IcEnwEj;2A?;operator delete::(0,38):_ZN2T5IcEdlEPv;2A?;value::(0,62)=#(0,54),(0,9),(0,56),(0,21);:_ZN2T5IcE5valueEv;2A.;;

Re: [RFC] Special casing dtors?

[Daniel Jacobowitz]

On Thu, Apr 02, 2009 at 09:25:34AM -0700, Keith Seitz wrote:
> Daniel Jacobowitz wrote:
>> On Wed, Apr 01, 2009 at 04:46:17PM -0700, Keith Seitz wrote:
>
>> I don't understand the patch - would you mind posting affected stabs
>> from 4.2 and HEAD?  Sounds like GCC made the incompatible change here,
>> not GDB.
>
> Stabs attached.
>
> Gcc did make the change, but as Pedro pointed out in a previous note,  
> "GDB has to cope with code produced from older compilers as well." Since  
> 4.2.0 and 4.2.4 are long out the door, I was simply attempting to  
> accommodating.

IIUC GCC replaced "__base_ctor" with "__base_ctor " at some point.
Assuming I've got that right, this patch is fine - please go ahead.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Special casing dtors?

[Mark Kettenis]

> Date: Wed, 01 Apr 2009 16:46:17 -0700
> From: Keith Seitz <keiths@redhat.com>
>
> I have run with gcc 4.2.0, 4.2.4, and gcc 4.3.2 releases (well, F10 
> w/4.3.2), and I was finally able to reproduce the failures you mention 
> with -gstabs+ (on the 4.2.x compilers). After digging into this for 
> quite some time, I am convinced this happens not because of my patch, 
> but because stabs is just really broken in gdb.

Well, stabs seems to work reasonable well for plain C on 32-bit
platforms.  But I think we basically gave up on stabs for C++ many
years ago already.  That's one of the reasons why basically all Open
Source Unix-like OSes switched to DWARF.

Re: [RFC] Special casing dtors?

[Pedro Alves]

On Thursday 02 April 2009 00:46:17, Keith Seitz wrote:
> Can you apply the attached patch to your tree and try again?

Since this stabs patch in now in HEAD, I've redone the testing.  I
confirm that with this patch installed, your original patch doesn't
introduce any new failures on the templates.exp test on
stabs --- gcc 4.2, or head.  Yay!

> So, I guess my position is that since stabs is so darn broken any way, 
> we might as well apply the patch and deal with the fallout. At least 
> then we'll know (and hopefully document) WHY all this special casing of 
> dtors is necessary.

On my end, your original patch is clear to go in.

> PS. I still don't understand how you are getting DWARF2 failures. I've 
> run these tests on gcc 4.2.0, 4.2.4, 4.3.2, and 4.4.0, and NONE of those 
> compilers demonstrate any failures after the patch; they all fail BEFORE 
> the patch is applied. I guess I'll deal with this next.

This must be a miscomunication.  I never said I was getting DWARF
failures.  I just re-confirmed that your original patch does remove
the dtors kfail in templates.exp on dwarf.

 -KFAIL: gdb.cp/templates.exp: destructor breakpoint (PRMS: gdb/1112)
 +PASS: gdb.cp/templates.exp: destructor breakpoint

-- 
Pedro Alves

Re: [RFC] Special casing dtors?

[Keith Seitz]

Pedro Alves wrote:

> Since this stabs patch in now in HEAD, I've redone the testing.  I
> confirm that with this patch installed, your original patch doesn't
> introduce any new failures on the templates.exp test on
> stabs --- gcc 4.2, or head.  Yay!

Phew! I was (really) worried there for a moment! :-)

>> PS. I still don't understand how you are getting DWARF2 failures. I've 
>> run these tests on gcc 4.2.0, 4.2.4, 4.3.2, and 4.4.0, and NONE of those 
>> compilers demonstrate any failures after the patch; they all fail BEFORE 
>> the patch is applied. I guess I'll deal with this next.
> 
> This must be a miscomunication.  I never said I was getting DWARF
> failures.  I just re-confirmed that your original patch does remove
> the dtors kfail in templates.exp on dwarf.

Ok, I must have misread your message -- my mind was quite overtaxed with 
all the testing and running through the debug info and whatnot whilst 
working on evaluating the stabs problems.

Once again, thank you for taking the time to investigate this so thoroughly.

Keith

Re: [RFC] Special casing dtors?

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Keith> Can you apply the attached patch to your tree and try again?

Pedro> Since this stabs patch in now in HEAD, I've redone the testing.  I
Pedro> confirm that with this patch installed, your original patch doesn't
Pedro> introduce any new failures on the templates.exp test on
Pedro> stabs --- gcc 4.2, or head.  Yay!

Keith> So, I guess my position is that since stabs is so darn broken any way, 
Keith> we might as well apply the patch and deal with the fallout. At least 
Keith> then we'll know (and hopefully document) WHY all this special casing of 
Keith> dtors is necessary.

Pedro> On my end, your original patch is clear to go in.

I re-read this whole thread this evening, and as far as I can tell,
the original cleanup patch is ok.  Early in the thread, Keith said
he'd send a new one that also removed get_destructor_fn_field.
Keith, could you do that?

thanks,
Tom

Re: [RFC] Special casing dtors?

[Keith Seitz]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Tom Tromey wrote:

> I re-read this whole thread this evening, and as far as I can tell,
> the original cleanup patch is ok.  Early in the thread, Keith said
> he'd send a new one that also removed get_destructor_fn_field.
> Keith, could you do that?

I've attached it.

Keith

ChangeLog
2009-04-24  Keith Seitz  <keiths@redhat.com>

	* gdbtypes.h (get_destructor_fn_field): Remove. No longer needed.
	* gdbtypes.c (get_destructor_fn_field): Likewise.


[-- Attachment #2: remove-get_dtor_fn_field.patch --]
[-- Type: text/plain, Size: 1620 bytes --]

Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.162
diff -u -p -r1.162 gdbtypes.c
--- gdbtypes.c	10 Apr 2009 03:36:32 -0000	1.162
+++ gdbtypes.c	24 Apr 2009 17:50:53 -0000
@@ -1334,34 +1334,6 @@ get_vptr_fieldno (struct type *type, str
     }
 }
 
-/* Find the method and field indices for the destructor in class type T.
-   Return 1 if the destructor was found, otherwise, return 0.  */
-
-int
-get_destructor_fn_field (struct type *t, 
-			 int *method_indexp, 
-			 int *field_indexp)
-{
-  int i;
-
-  for (i = 0; i < TYPE_NFN_FIELDS (t); i++)
-    {
-      int j;
-      struct fn_field *f = TYPE_FN_FIELDLIST1 (t, i);
-
-      for (j = 0; j < TYPE_FN_FIELDLIST_LENGTH (t, i); j++)
-	{
-	  if (is_destructor_name (TYPE_FN_FIELD_PHYSNAME (f, j)) != 0)
-	    {
-	      *method_indexp = i;
-	      *field_indexp = j;
-	      return 1;
-	    }
-	}
-    }
-  return 0;
-}
-
 static void
 stub_noname_complaint (void)
 {
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.100
diff -u -p -r1.100 gdbtypes.h
--- gdbtypes.h	26 Mar 2009 01:27:45 -0000	1.100
+++ gdbtypes.h	24 Apr 2009 17:50:53 -0000
@@ -1201,8 +1201,6 @@ extern struct type *lookup_template_type
 
 extern int get_vptr_fieldno (struct type *, struct type **);
 
-extern int get_destructor_fn_field (struct type *, int *, int *);
-
 extern int get_discrete_bounds (struct type *, LONGEST *, LONGEST *);
 
 extern int is_ancestor (struct type *, struct type *);

Re: [RFC] Special casing dtors?

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Tom> I re-read this whole thread this evening, and as far as I can tell,
Tom> the original cleanup patch is ok.  Early in the thread, Keith said
Tom> he'd send a new one that also removed get_destructor_fn_field.
Tom> Keith, could you do that?

Keith> 2009-04-24  Keith Seitz  <keiths@redhat.com>
Keith> 	* gdbtypes.h (get_destructor_fn_field): Remove. No longer needed.
Keith> 	* gdbtypes.c (get_destructor_fn_field): Likewise.

This patch and the original patch are both ok.
Thanks.

Tom

Re: [RFC] Special casing dtors?

[Keith Seitz]

Tom Tromey wrote:
> This patch and the original patch are both ok.
> Thanks.

Thank you for reminding me that I had not yet committed this patch. 
Since there has been almost twelve weeks without any objections or other 
comments, I have now finally committed these patches.

Keith

Re: [RFC] Special casing dtors?

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Pedro> With stabs?  FSF GDB?  I *do* see that with dwarf.  I'll see if I
Pedro> can try this on x86-cygwin, which is currently still using
Pedro> gcc-3.4/stabs by default.

Keith> BTW, I ran the testsuite on x86 and x86_64 w/stabs (again, using the
Keith> F10 compiler), and the summaries are absolutely identical (timestamp
Keith> excepted): the patch has no effect.

I tried this on x86 F9 using -gstabs+ and those tests pass for me as well.
I used the system gcc (4.3 based).

At this point I would assume the discrepancy is due to compiler
differences.

Tom