[PATCH] gdb.c++/method.exp

[PATCH] gdb.c++/method.exp

[Michael Elizabeth Chastain]

I am committing the following patch to gdb.c++/method.exp.

This cleans up the script considerably.   It also fixes several spurious
FAILs by accepting "A * const" and "const A * const".

After applying this patch, there is still 1 FAIL in two configurations:
"print this in A::bar" still FAILs on native i686-pc-linux-gnu with
gcc gcc-3_1-branch and gcc HEAD.

Michael C

2002-04-07  Michael Chastain  <mec@shout.net>

	* gdb.c++/method.exp: Use gdb_test instead of send_gdb/gdb_expect.
	Accept "A * const" and "const A * const" as type of "this".
	Fix spelling of getFunky throughout.  Make messages uniform.

Index: method.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/method.exp,v
retrieving revision 1.5
diff -c -3 -p -r1.5 method.exp
*** method.exp	20 Jan 2002 19:46:32 -0000	1.5
--- method.exp	8 Apr 2002 07:14:16 -0000
*************** if ![runto_main] then {
*** 70,226 ****
      continue
  }
  
! send_gdb "break A::foo\n"
! gdb_expect {
!    -re "Breakpoint \[0-9\]* at $hex.*file .*method.cc, line 38*\\.\r\n$gdb_prompt $" {
!        pass "set breakpoint on A::foo"
!    }
!    -re ".*$gdb_prompt $" { fail "set breakpoint on A::foo" }
!    timeout { fail "(timeout) set breakpoint on A::foo" }
! }
  
! send_gdb "continue\n"
! gdb_expect {
!    -re "Continuing\\.\r\n\r\nBreakpoint \[0-9\]*, A::foo(\\(int\\)|) \\(this=$hex, arg=13\\) at .*method\\.cc:38\r\n38\[\t \]*x \\+= arg;\r\n$gdb_prompt $" {
!       pass "continued and got breakpoint in A::foo"
!    }
!    -re ".*$gdb_prompt $" { fail "continuing and breaking in A::foo" }
!    timeout { fail "(timeout) continue" }
! }
  
  # Check ability to access this-relative stuff.
  
! send_gdb "print x\n"
! gdb_expect {
!    -re "\\$\[0-9\]* = 20\r\n$gdb_prompt $" {
!        pass "access this-relative x (in foo)"
!    }
!    -re ".*$gdb_prompt $" { fail "print x (in foo)" } 
!    timeout { fail "(timeout) print x (in foo)" }
! }
  
  # Check access to this pointer       
  
! send_gdb "print this\n"
! gdb_expect {
!    -re "\\$\[0-9\]* = \\(A \\*\\) $hex\r\n$gdb_prompt $" {
!        pass "print this (in foo)"
!    }
!    -re ".*$gdb_prompt $" { fail "print this (in foo)" }
!    timeout { fail "(timeout) print this (in foo)" }
! }
  
  # Now do everything over again for A::bar, because sometimes processing one method
  # (the first one) is fine, but the second one's debug info gets munged beyond recognition.
  
! send_gdb "break A::bar\n"
! gdb_expect {
!    -re "Breakpoint \[0-9\]* at $hex.*file .*method.cc, line 44\\.\r\n$gdb_prompt $" {
!        pass "set breakpoint on A::bar"
!    }
!    -re ".*$gdb_prompt $" { fail "set breakpoint on A::bar" }
!    timeout { fail "(timeout) set breakpoint on A::bar" }
! }
  
! send_gdb "continue\n"
! gdb_expect {
!    -re "Continuing\\.\r\n\r\nBreakpoint \[0-9\]*, A::bar(\\(int\\) const|) \\(this=$hex, arg=15\\) at .*method\\.cc:44\r\n44\[\t \]*return arg \\+ 2 \\* x;\r\n$gdb_prompt $" {
!       pass "continued and got breakpoint in A::bar"
!    }
!    -re ".*$gdb_prompt $" { fail "continuing and breaking in A::bar" }
!    timeout { fail "(timeout) continue" }
! }
  
  # Check ability to access this-relative stuff.
  
! send_gdb "print x\n"
! gdb_expect {
!    -re "\\$\[0-9\]* = 33\r\n$gdb_prompt $" {
!        pass "access this-relative x (in bar)"
!    }
!    -re ".*$gdb_prompt $" { fail "print x (in bar)" }
!    timeout { fail "(timeout) print x (in bar)" }
! }
  
  # Check access to this pointer       
  
! send_gdb "print this\n"
! gdb_expect {
!    -re "\\$\[0-9\]* = \\(const class A \\*\\) $hex\r\n$gdb_prompt $" {
!      global gcc_compiled
!      if {$gcc_compiled} {
!        xfail "print this (in bar)"
!      } else {
!        pass "print this (in bar)"
!      }
!    }
!    -re "\\$\[0-9\]* = \\(A \\*\\) $hex\r\n$gdb_prompt $" {
!      global gcc_compiled
!      if {$gcc_compiled} {
!        pass "print this (in bar)"
!      } else {
!        xfail "print this (in bar)"
!      }
!    }
!    -re ".*$gdb_prompt $" { fail "print this (in bar)" }
!    timeout { fail "(timeout) print this (in bar)" }
! }
  
  # Check again with funk::getFunky (this is the original test case
  # for CHFts23426); sometimes having a constructor with no arguments
  # will nuke the debug info read in for other methods in the class.
  
! send_gdb "break funk::getFunky\n"
! gdb_expect {
!    -re "Breakpoint \[0-9\]* at $hex.*file .*method.cc, line 20\\.\r\n$gdb_prompt $" {
!        pass "set breakpoint on funk::getFunky"
!    }
!    -re ".*$gdb_prompt $" { fail "set breakpoint on funk::getfunky" }
!    timeout { fail "(timeout) set breakpoint on funk::getfunky" }
! }
  
! send_gdb "continue\n"
! gdb_expect {
!    -re "Continuing\\.\r\n\r\nBreakpoint \[0-9\]*, funk::getFunky(\\(int, int\\)|) \\(this=$hex, a=1, b=2\\) at .*method\\.cc:20\r\n20\[\t \]*res = a \\+ b - data_;\r\n$gdb_prompt $" {
!       pass "continued and got breakpoint in funk::getfunky"
!    }
!    -re ".*$gdb_prompt $" { fail "continuing and breaking in funk::getfunky" }
!    timeout { fail "(timeout) continue" }
! }
  
  # Check ability to access this-relative stuff.
  
! send_gdb "print data_\n"
! gdb_expect {
!    -re "\\$\[0-9\]* = 33\r\n$gdb_prompt $" {
!        pass "access this-relative data_ in getFunky"
!    }
!    -re ".*$gdb_prompt $" { fail "print data_ in getFunky" }
!    timeout { fail "(timeout) print data_ in getFunky" }
! }
  
  # Check access to this pointer       
  
! send_gdb "print this\n"
! gdb_expect {
!    -re "\\$\[0-9\]* = \\(funk \\*\\) $hex\r\n$gdb_prompt $" {
!        pass "print this in getFunky"
!    }
!    -re ".*$gdb_prompt $" { fail "print this in getfunky" }
!    timeout { fail "(timeout) print this in getfunky" }
! }
  
  # Check access to local variable
  
! send_gdb "print res\n"
! gdb_expect {
!    -re "\\$\[0-9\]* = .\[0-9\]*\r\n$gdb_prompt $" {
!        pass "print res in getFunky"
!    }
!    -re ".*$gdb_prompt $" { fail "print res in getfunky" }
!    timeout { fail "(timeout) print res in getfunky" }
! }
! 
  
  # Check ptype of class -- should show const/volatile methods
  
--- 70,144 ----
      continue
  }
  
! gdb_test "break A::foo" \
!   "Breakpoint \[0-9\]* at $hex.*file .*method.cc, line 38\\."
  
! gdb_test "continue" \
!   "Continuing\\.\r\n\r\nBreakpoint \[0-9\]*, A::foo(\\(int\\)|) \\(this=$hex, arg=13\\) at .*method\\.cc:38\r\n38\[\t \]*x \\+= arg;" \
!   "continue to A::foo"
  
  # Check ability to access this-relative stuff.
  
! gdb_test "print x" \
!    "\\$\[0-9\]* = 20" \
!    "print x in A::foo"
  
  # Check access to this pointer       
  
! gdb_test "print this" \
!    "\\$\[0-9\]* = \\((class |)A *\\* *(const|)\\) $hex" \
!    "print this in A::foo"
  
  # Now do everything over again for A::bar, because sometimes processing one method
  # (the first one) is fine, but the second one's debug info gets munged beyond recognition.
  
! gdb_test "break A::bar" \
!   "Breakpoint \[0-9\]* at $hex.*file .*method.cc, line 44\\."
  
! gdb_test "continue" \
!   "Continuing\\.\r\n\r\nBreakpoint \[0-9\]*, A::bar(\\(int\\) const|) \\(this=$hex, arg=15\\) at .*method\\.cc:44\r\n44\[\t \]*return arg \\+ 2 \\* x;" \
!   "continue to A::bar"
  
  # Check ability to access this-relative stuff.
  
! gdb_test "print x" \
!   "\\$\[0-9\]* = 33" \
!   "print x in A::bar"
  
  # Check access to this pointer       
  
! gdb_test "print this" \
!   "\\$\[0-9\]* = \\((const |)(class |)A *\\* *(const|)\\) $hex" \
!   "print this in A::bar"
  
  # Check again with funk::getFunky (this is the original test case
  # for CHFts23426); sometimes having a constructor with no arguments
  # will nuke the debug info read in for other methods in the class.
  
! gdb_test "break 21" \
!   "Breakpoint \[0-9\]* at $hex.*file .*method.cc, line 21\\."
  
! gdb_test "continue" \
!   "Continuing\\.\r\n\r\nBreakpoint \[0-9\]*, funk::getFunky(\\(int, int\\)|) \\(this=$hex, a=1, b=2\\) at .*method\\.cc:21\r\n21\[\t \]*data_ = res;" \
!   "continue to 21"
  
  # Check ability to access this-relative stuff.
  
! gdb_test "print data_" \
!   "\\$\[0-9\]* = 33" \
!   "print data_ in funk::getFunky"
  
  # Check access to this pointer       
  
! gdb_test "print this" \
!   "\\$\[0-9\]* = \\((class |)funk *\\* *(const|)\\) $hex" \
!   "print this in funk::getFunky"
  
  # Check access to local variable
  
! gdb_test "print res" \
!   "\\$\[0-9\]* = -30" \
!    "print res in funk::getFunky"
  
  # Check ptype of class -- should show const/volatile methods
  
*************** gdb_expect {
*** 242,253 ****
     timeout { fail "(timeout) ptype A" }
  }
  
! send_gdb "cont\n"
! gdb_expect {
!     -re "Continuing.\r\n\r\nProgram exited normally.\r\n$gdb_prompt $" {
!         pass "finish program"
!     }
!     -re "$gdb_prompt $" { fail "finish program"  }
!     timeout { fail "(timeout) finish program"  }
! }
! 
--- 160,165 ----
     timeout { fail "(timeout) ptype A" }
  }
  
! gdb_test "cont" \
!   "Continuing.\r\n\r\nProgram exited normally." \
!   "finish program"

Re: [PATCH] gdb.c++/method.exp

[Daniel Jacobowitz]

On Mon, Apr 08, 2002 at 02:21:41AM -0500, Michael Elizabeth Chastain wrote:
> I am committing the following patch to gdb.c++/method.exp.
> 
> This cleans up the script considerably.   It also fixes several spurious
> FAILs by accepting "A * const" and "const A * const".
> 
> After applying this patch, there is still 1 FAIL in two configurations:
> "print this in A::bar" still FAILs on native i686-pc-linux-gnu with
> gcc gcc-3_1-branch and gcc HEAD.

Erm... did we reach a conclusion about whether those const's were
really optional?  In a const method, there should be a const on the
type of 'this'.  Obviously we won't get it in g++2.95/stabs, and I
think we agreed that the latter const is optional (on the *); but the
const on 'A' should be part of the type of this for a const method.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] gdb.c++/method.exp

[Michael Elizabeth Chastain]

Committed.

Michael C

2002-04-07  Michael Chastain  <mec@shout.net>

	* gdb.c++/method.exp: Use gdb_test instead of send_gdb/gdb_expect.
	Accept "A * const" and "const A * const" as type of "this".
	Fix spelling of getFunky throughout.  Make messages uniform.

Re: [PATCH] gdb.c++/method.exp

[Michael Elizabeth Chastain]

Good morning Daniel,
> Erm... did we reach a conclusion about whether those const's were
> really optional?  In a const method, there should be a const on the
> type of 'this'.

The old script accepted these strings:

  // non-const method
    "A *" => PASS
    default => FAIL

  // const method, gcc_compiled=TRUE
    "A *" => PASS
    "const class A *" => XFAIL
    default => FAIL

  // const method, gcc_compiled=FALSE
    "const class A *" => PASS
    "A *" => XFAIL
    default => FAIL

  // non-const method
    "funk *" => PASS
    default => FAIL

One problem is that none of the tests accepted the second "const"
after the "*".  Another problem, obviously, is the weird logic
for const methods that depends on gcc_compiled, and *rejects*
"const A *" for const methods when gcc_compiled=TRUE.

The new script accepts these strings:

  // non-const method
    "class A * const" => PASS
    "class A *" => PASS
    "A * const" => PASS
    "A *" => PASS
    default => FAIL

  // const method
    "const class A * const" => PASS
    "const class A *" => PASS
    "const A * const" => PASS
    "const A *" => PASS
    "class A * const" => PASS
    "class A *" => PASS
    "A * const" => PASS
    "A *" => PASS
    default => FAIL

  // non-const method
    "class A * const" => PASS
    "class A *" => PASS
    "A * const" => PASS
    "A *" => PASS
    default => FAIL

So the old script reported FAIL to "const A *" for a constant method
when the compiler is gcc.  The new script reports PASS.  That's a
definite improvement.

The old script reported PASS to "A *" for a constant method when the
compiler is gcc.  That is problematic.  Right now the new script also
reports PASS, to be compatible with the old script.

Now is a good time to break compatibility anyways.  The new script looks
like this right now (for a const method):

  gdb_test "print this" \
    "\\$\[0-9\]* = \\((const |)(class |)A *\\* *(const|)\\) $hex" \
    "print this in A::bar"

What do you think of this:

  gdb_test "print this" \
    "\\$\[0-9\]* = \\(const (class |)A *\\* *(const|)\\) $hex" \
    "print this in A::bar"

Michael C

Re: [PATCH] gdb.c++/method.exp

[Daniel Jacobowitz]

On Mon, Apr 08, 2002 at 10:12:46AM -0500, Michael Elizabeth Chastain wrote:
> Good morning Daniel,
> > Erm... did we reach a conclusion about whether those const's were
> > really optional?  In a const method, there should be a const on the
> > type of 'this'.
> 
> The old script accepted these strings:
> 
>   // non-const method
>     "A *" => PASS
>     default => FAIL
> 
>   // const method, gcc_compiled=TRUE
>     "A *" => PASS
>     "const class A *" => XFAIL
>     default => FAIL
> 
>   // const method, gcc_compiled=FALSE
>     "const class A *" => PASS
>     "A *" => XFAIL
>     default => FAIL
> 
>   // non-const method
>     "funk *" => PASS
>     default => FAIL
> 
> One problem is that none of the tests accepted the second "const"
> after the "*".  Another problem, obviously, is the weird logic
> for const methods that depends on gcc_compiled, and *rejects*
> "const A *" for const methods when gcc_compiled=TRUE.
> 
> The new script accepts these strings:
> 
>   // non-const method
>     "class A * const" => PASS
>     "class A *" => PASS
>     "A * const" => PASS
>     "A *" => PASS
>     default => FAIL
> 
>   // const method
>     "const class A * const" => PASS
>     "const class A *" => PASS
>     "const A * const" => PASS
>     "const A *" => PASS
>     "class A * const" => PASS
>     "class A *" => PASS
>     "A * const" => PASS
>     "A *" => PASS
>     default => FAIL
> 
>   // non-const method
>     "class A * const" => PASS
>     "class A *" => PASS
>     "A * const" => PASS
>     "A *" => PASS
>     default => FAIL
> 
> So the old script reported FAIL to "const A *" for a constant method
> when the compiler is gcc.  The new script reports PASS.  That's a
> definite improvement.

Yes, it is!

> The old script reported PASS to "A *" for a constant method when the
> compiler is gcc.  That is problematic.  Right now the new script also
> reports PASS, to be compatible with the old script.
> 
> Now is a good time to break compatibility anyways.  The new script looks
> like this right now (for a const method):
> 
>   gdb_test "print this" \
>     "\\$\[0-9\]* = \\((const |)(class |)A *\\* *(const|)\\) $hex" \
>     "print this in A::bar"
> 
> What do you think of this:
> 
>   gdb_test "print this" \
>     "\\$\[0-9\]* = \\(const (class |)A *\\* *(const|)\\) $hex" \
>     "print this in A::bar"

I think this is right.  That will cause failures for 2.95/stabs and
3.0/stabs; we can XFAIL appropriately (based on version numbers even!).

Does anything currently produce A const * const?  It's probably
legal...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] gdb.c++/method.exp

[Michael Elizabeth Chastain]

Daniel Jacobowitz writes:
> Does anything currently produce A const * const?  It's probably
> legal...

I haven't seen any "A const * const".  I guess I would have to accommodate
that if somebody saw one.  I'm not inclined to put it in at this time.

Here's what I've got (2002-04-04, native i686-pc-linux-gnu):

  const A * const
    gcc 2.95.3 -gdwarf-2
    gcc 2.96-rh -gdwarf-2
    gcc 3.0.4 -gdwarf-2
    gcc gcc-3_1-branch -gdwarf-2
    gcc HEAD -gdwarf-2

  A *
    gcc 2.95.3 -gstabs+
    gcc 2.96-rh -gstabs+
    gcc 3.0.4 -gstabs+

  const class {...} * const
    gcc gcc-3_1-branch -gstabs+
    gcc HEAD -gstabs+

"const A * const" should always be a PASS.

"A *" should be a FAIL or an XFAIL, depending on what is in the
generated code.  If gcc is omitting the const then it's an XFAIL.
I will grub around in the generated code to figure that out.

"const class {...} * const" looks like a gdb bug to me.  Again I will
look in the generated code.  That will likely be a FAIL with a bug
report (soon to be a KFAIL).

Michael C

Re: [PATCH] gdb.c++/method.exp

[Daniel Jacobowitz]

On Mon, Apr 08, 2002 at 12:17:24PM -0500, Michael Elizabeth Chastain wrote:
> Daniel Jacobowitz writes:
> > Does anything currently produce A const * const?  It's probably
> > legal...
> 
> I haven't seen any "A const * const".  I guess I would have to accommodate
> that if somebody saw one.  I'm not inclined to put it in at this time.

Agree.

> Here's what I've got (2002-04-04, native i686-pc-linux-gnu):
> 
>   const A * const
>     gcc 2.95.3 -gdwarf-2
>     gcc 2.96-rh -gdwarf-2
>     gcc 3.0.4 -gdwarf-2
>     gcc gcc-3_1-branch -gdwarf-2
>     gcc HEAD -gdwarf-2

Legitimate.

>   A *
>     gcc 2.95.3 -gstabs+
>     gcc 2.96-rh -gstabs+
>     gcc 3.0.4 -gstabs+

XFAIL.

>   const class {...} * const
>     gcc gcc-3_1-branch -gstabs+
>     gcc HEAD -gstabs+

Broken.

> "const class {...} * const" looks like a gdb bug to me.  Again I will
> look in the generated code.  That will likely be a FAIL with a bug
> report (soon to be a KFAIL).

There is a PR for this, though it isn't obvious.  It's... uhm....
gdb/277.  I even describe the solution.  I'm too busy to do it this
week, but hopefully soon.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer