[RFA/testsuite] test hand function call in commands list

[RFA/testsuite] test hand function call in commands list

[Joel Brobecker]

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

The attached patch to break.exp was written by Klee Dienes and
submitted in the following message:

        http://sources.redhat.com/ml/gdb-patches/2002-10/msg00586.html

The purpose of the test is to make sure that a problem occuring with
function calls inside a commands list does not cause a SIGSEGV.

2003-04-14  J. Brobecker  <brobecker@gnat.com>

        From Klee Dienne <kdienes@apple.com>
        * gdb.base/break.exp: Add multiple calls to the inferior in
        the user-commands for 'break 79'. Add a check for the calls
        to the inferior in the check for the result. Add new test, to
        check that user-defined breakpoint commands are called for functions
        called by the user (currently fails).

When I ran the test, I was very surprised to see one FAIL. I am
describing below the symptoms (no time to investigate this today), but I
think the test is worthwhile adding anyway. Ok to apply?

Here is a small description of the problem:

The test itself inserted a breakpoint in marker2. It then makes a hand
function call to this function. Here is the output from the logs:

| print marker2(99)
|
| Breakpoint 26, marker2 (a=99) at ./gdb.base/break.c:49    <<<---
| 49      int marker2 (a) int a; { return (1); }
| The program being debugged stopped while in a function called from GDB.
| When the function (marker2) is done executing, GDB will silently
| stop (instead of continuing to evaluate the expression containing
| the function call).

Klee's patch then adds a commands list to the breakpoint in maker2:

| commands 26
| Type commands for when breakpoint 26 is hit, one per line.
| End with a line saying just "end".
| >silent
| >call (int) printf ("PREFIXbobo\n" + (int) strlen ("PREFIXbobo\n") - 5)
| >end

And calls marker2 again:

| print marker2(99)
| The program being debugged stopped while in a function called from GDB.
| When the function (marker2) is done executing, GDB will silently
| stop (instead of continuing to evaluate the expression containing
| the function call).

The fact that GDB did not print the breakpoint number shows that GDB
started evaluating the commands list. However, we did not get the
output from the printf command, which means that the evaluation stopped
prematurely for some reason. 

I will be happy to have a look at this problem sometime in the future.
But, if somebody else would like to have a look, no problem either.

Thanks,
-- 
Joel

[-- Attachment #2: break.exp.diff --]
[-- Type: text/plain, Size: 4430 bytes --]

Index: break.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/break.exp,v
retrieving revision 1.17
diff -c -3 -p -r1.17 break.exp
*** break.exp	5 Apr 2003 13:35:25 -0000	1.17
--- break.exp	14 Apr 2003 14:46:41 -0000
*************** gdb_expect {
*** 423,429 ****
  }
  
  # Verify that a "silent" breakpoint can be set, and that GDB is indeed
! # "silent" about its triggering.
  #
  if ![runto_main] then { fail "break tests suppressed" }
  
--- 423,431 ----
  }
  
  # Verify that a "silent" breakpoint can be set, and that GDB is indeed
! # "silent" about its triggering.  Include multiple nested calls to the
! # inferior in the user-commands for the breakpoint, to verify that the
! # cleanup code isn't trashing stop_bpstat.
  #
  if ![runto_main] then { fail "break tests suppressed" }
  
*************** gdb_expect {
*** 438,443 ****
--- 440,446 ----
  
  send_gdb "commands $expect_out(1,string)\n"
  send_gdb "silent\n"
+ send_gdb "call (int) printf (\"PREFIXbobo\\n\" + (int) strlen (\"PREFIXbobo\\n\") - 5)\n"
  send_gdb "end\n"
  gdb_expect {
    -re ".*$gdb_prompt $"\
*************** gdb_expect {
*** 455,461 ****
  }
  send_gdb "continue\n"
  gdb_expect {
!   -re "Continuing.\r\n$gdb_prompt $"\
            {pass "hit silent break 79"}
    -re "$gdb_prompt $"\
            {fail "hit silent break 79"}
--- 458,464 ----
  }
  send_gdb "continue\n"
  gdb_expect {
!   -re "Continuing.\r\nbobo\r\n\\\$\[0-9\]* = 5\r\n$gdb_prompt $"\
            {pass "hit silent break 79"}
    -re "$gdb_prompt $"\
            {fail "hit silent break 79"}
*************** gdb_expect {
*** 585,590 ****
--- 588,600 ----
            {fail "set breakpoint on to-be-called function"}
    timeout {fail "(timeout) set breakpoint on to-be-called function"}
  }
+ 
+ # save the breakpoint identifier for future use
+ #
+ set marker2_bpnum $expect_out(1,string)
+ 
+ # Call the function.
+ #
  send_gdb "print marker2(99)\n"
  gdb_expect {
    -re "The program being debugged stopped while in a function called from GDB.\r\nWhen the function .marker2$proto. is done executing, GDB will silently\r\nstop .instead of continuing to evaluate the expression containing\r\nthe function call...*$gdb_prompt $"\
*************** gdb_expect {
*** 609,614 ****
--- 619,664 ----
      -re "$gdb_prompt $"\
              {fail "backtrace while in called function"}
      timeout {fail "(timeout) backtrace while in called function"}
+ }
+ 
+ # Return from the called function.  For remote targets, it's important to do
+ # this before runto_main, which otherwise may silently stop on the dummy
+ # breakpoint inserted by GDB at the program's entry point.
+ #
+ send_gdb "finish\n"
+ gdb_expect {
+     -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.* in _sr4export.*$gdb_prompt $"\
+             {pass "finish from called function"}
+     -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.*function called from gdb.*$gdb_prompt $"\
+             {pass "finish from called function"}
+     -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.*Value returned.*$gdb_prompt $"\
+             {pass "finish from called function"}
+     -re "$gdb_prompt $"\
+             {fail "finish from called function"}
+     timeout {fail "(timeout) finish from called function"}
+ }
+ 
+ # Add a user-command that calls the inferior to the breakpoint for marker2.
+ #
+ send_gdb "commands $marker2_bpnum\n"
+ send_gdb "silent\n"
+ send_gdb "call (int) printf (\"PREFIXbobo\\n\" + (int) strlen (\"PREFIXbobo\\n\") - 5)\n"
+ send_gdb "end\n"
+ gdb_expect {
+   -re ".*$gdb_prompt $"\
+           {pass "set printf break marker2"}
+   timeout {fail "(timeout) set printf break marker2"}
+ }
+ 
+ # Call the function again.
+ #
+ send_gdb "print marker2(99)\n"
+ gdb_expect {
+     -re "The program being debugged stopped while in a function called from GDB.\r\nWhen the function .marker2$proto. is done executing, GDB will silently\r\nstop .instead of continuing to evaluate the expression containing\r\nthe function call...*bobo.*$gdb_prompt $"\
+ 	{pass "called user-defined function on breakpoint in called function"}
+     -re "$gdb_prompt $"\
+ 	{fail "called user-defined function on breakpoint in called function"}
+     timeout {fail "called user-defined function on breakpoint in called function"}
  }
  
  # Return from the called function.  For remote targets, it's important to do

Re: [RFA/testsuite] test hand function call in commands list

[Daniel Jacobowitz]

On Mon, Apr 14, 2003 at 11:40:48AM -0400, Joel Brobecker wrote:
> The attached patch to break.exp was written by Klee Dienes and
> submitted in the following message:
> 
>         http://sources.redhat.com/ml/gdb-patches/2002-10/msg00586.html
> 
> The purpose of the test is to make sure that a problem occuring with
> function calls inside a commands list does not cause a SIGSEGV.
> 
> 2003-04-14  J. Brobecker  <brobecker@gnat.com>
> 
>         From Klee Dienne <kdienes@apple.com>
>         * gdb.base/break.exp: Add multiple calls to the inferior in
>         the user-commands for 'break 79'. Add a check for the calls
>         to the inferior in the check for the result. Add new test, to
>         check that user-defined breakpoint commands are called for functions
>         called by the user (currently fails).
> 
> When I ran the test, I was very surprised to see one FAIL. I am
> describing below the symptoms (no time to investigate this today), but I
> think the test is worthwhile adding anyway. Ok to apply?

No; let's figure out what the new problem is first.  After that let's
get the test in as quickly as possible so that we know if it breaks
again :)

> Here is a small description of the problem:
> 
> The test itself inserted a breakpoint in marker2. It then makes a hand
> function call to this function. Here is the output from the logs:
> 
> | print marker2(99)
> |
> | Breakpoint 26, marker2 (a=99) at ./gdb.base/break.c:49    <<<---
> | 49      int marker2 (a) int a; { return (1); }
> | The program being debugged stopped while in a function called from GDB.
> | When the function (marker2) is done executing, GDB will silently
> | stop (instead of continuing to evaluate the expression containing
> | the function call).
> 
> Klee's patch then adds a commands list to the breakpoint in maker2:
> 
> | commands 26
> | Type commands for when breakpoint 26 is hit, one per line.
> | End with a line saying just "end".
> | >silent
> | >call (int) printf ("PREFIXbobo\n" + (int) strlen ("PREFIXbobo\n") - 5)
> | >end
> 
> And calls marker2 again:
> 
> | print marker2(99)
> | The program being debugged stopped while in a function called from GDB.
> | When the function (marker2) is done executing, GDB will silently
> | stop (instead of continuing to evaluate the expression containing
> | the function call).
> 
> The fact that GDB did not print the breakpoint number shows that GDB
> started evaluating the commands list. However, we did not get the
> output from the printf command, which means that the evaluation stopped
> prematurely for some reason. 
> 
> I will be happy to have a look at this problem sometime in the future.
> But, if somebody else would like to have a look, no problem either.

I can reproduce this.  It's even simpler; we aren't executing the
commands list even if if there's no inferior function call in them. 
This appears to be specific to commands on a breakpoint hit during an
inferior function call.

Did this ever work?  It looks like the call to error() when we stop in
call_function_by_hand drops us out in start_event_loop, but the call to
bpstat_do_actions is in command_handler (closer to the innermost end of
the call chain, and thus bypassed by the error()).

Should we be calling bpstat_do_actions before that error()?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/testsuite] test hand function call in commands list

[Joel Brobecker]

> No; let's figure out what the new problem is first.  After that let's
> get the test in as quickly as possible so that we know if it breaks
> again :)

Sure.

> I can reproduce this.  It's even simpler; we aren't executing the
> commands list even if if there's no inferior function call in them. 
> This appears to be specific to commands on a breakpoint hit during an
> inferior function call.

This is really bizarre. I do remember very clearly that removing the
"silent" command in the commands list caused the breakpoint number to
be printed. So it seemed that the commands where executed...

> Did this ever work?

Since Klee posted the patch, I was assuming that he had it working at
some point.

-- 
Joel

Re: [RFA/testsuite] test hand function call in commands list

[Daniel Jacobowitz]

On Wed, Apr 16, 2003 at 07:09:05PM -0400, Joel Brobecker wrote:
> > No; let's figure out what the new problem is first.  After that let's
> > get the test in as quickly as possible so that we know if it breaks
> > again :)
> 
> Sure.
> 
> > I can reproduce this.  It's even simpler; we aren't executing the
> > commands list even if if there's no inferior function call in them. 
> > This appears to be specific to commands on a breakpoint hit during an
> > inferior function call.
> 
> This is really bizarre. I do remember very clearly that removing the
> "silent" command in the commands list caused the breakpoint number to
> be printed. So it seemed that the commands where executed...

Silent is handled separately from the rest of the commands list; it's
handled when the breakpoint is hit, but the commands themselves run
later.

> > Did this ever work?
> 
> Since Klee posted the patch, I was assuming that he had it working at
> some point.

I don't know if it was tested in the FSF tree.  Although yes is
probably a safe bet...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/testsuite] test hand function call in commands list

[Joel Brobecker]

> I can reproduce this.  It's even simpler; we aren't executing the
> commands list even if if there's no inferior function call in them. 
> This appears to be specific to commands on a breakpoint hit during an
> inferior function call.
> 
> Did this ever work?  It looks like the call to error() when we stop in
> call_function_by_hand drops us out in start_event_loop, but the call to
> bpstat_do_actions is in command_handler (closer to the innermost end of
> the call chain, and thus bypassed by the error()).
> 
> Should we be calling bpstat_do_actions before that error()?

I had a quick look: This ``feature'' is present since at least 5.1.1
(I tried on Linux with 5.1.1, 5.2.1 and 5.3 - could not try with 5.0
as it had a problem reading DWARF2_FORM_strp). I don't know how Klee
got it to work.

Here is what I suggest: This issue is orthogonal to what we are trying
to test, so let's write a new test for it that does not rely on inferior
function calls to hit the breakpoints. We can also discuss whether we
consider this feature to be a bug or not.

What do you think?
-- 
Joel

Re: [RFA/testsuite] test hand function call in commands list

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Mon, Apr 14, 2003 at 11:40:48AM -0400, Joel Brobecker wrote:
> > The attached patch to break.exp was written by Klee Dienes and
> > submitted in the following message:
> >
> >         http://sources.redhat.com/ml/gdb-patches/2002-10/msg00586.html
> >
> > The purpose of the test is to make sure that a problem occuring with
> > function calls inside a commands list does not cause a SIGSEGV.
> >
> > 2003-04-14  J. Brobecker  <brobecker@gnat.com>
> >
> >         From Klee Dienne <kdienes@apple.com>
> >         * gdb.base/break.exp: Add multiple calls to the inferior in
> >         the user-commands for 'break 79'. Add a check for the calls
> >         to the inferior in the check for the result. Add new test, to
> >         check that user-defined breakpoint commands are called for functions
> >         called by the user (currently fails).
> >
> > When I ran the test, I was very surprised to see one FAIL. I am
> > describing below the symptoms (no time to investigate this today), but I
> > think the test is worthwhile adding anyway. Ok to apply?
> 
> No; let's figure out what the new problem is first.  After that let's
> get the test in as quickly as possible so that we know if it breaks
> again :)
> 
> > Here is a small description of the problem:
> >
> > The test itself inserted a breakpoint in marker2. It then makes a hand
> > function call to this function. Here is the output from the logs:
> >
> > | print marker2(99)
> > |
> > | Breakpoint 26, marker2 (a=99) at ./gdb.base/break.c:49    <<<---
> > | 49      int marker2 (a) int a; { return (1); }
> > | The program being debugged stopped while in a function called from GDB.
> > | When the function (marker2) is done executing, GDB will silently
> > | stop (instead of continuing to evaluate the expression containing
> > | the function call).
> >
> > Klee's patch then adds a commands list to the breakpoint in maker2:
> >
> > | commands 26
> > | Type commands for when breakpoint 26 is hit, one per line.
> > | End with a line saying just "end".
> > | >silent
> > | >call (int) printf ("PREFIXbobo\n" + (int) strlen ("PREFIXbobo\n") - 5)
> > | >end
> >
> > And calls marker2 again:
> >
> > | print marker2(99)
> > | The program being debugged stopped while in a function called from GDB.
> > | When the function (marker2) is done executing, GDB will silently
> > | stop (instead of continuing to evaluate the expression containing
> > | the function call).
> >
> > The fact that GDB did not print the breakpoint number shows that GDB
> > started evaluating the commands list. However, we did not get the
> > output from the printf command, which means that the evaluation stopped
> > prematurely for some reason.
> >
> > I will be happy to have a look at this problem sometime in the future.
> > But, if somebody else would like to have a look, no problem either.
> 
> I can reproduce this.  It's even simpler; we aren't executing the
> commands list even if if there's no inferior function call in them.
> This appears to be specific to commands on a breakpoint hit during an
> inferior function call.
> 
> Did this ever work?  It looks like the call to error() when we stop in
> call_function_by_hand drops us out in start_event_loop, but the call to
> bpstat_do_actions is in command_handler (closer to the innermost end of
> the call chain, and thus bypassed by the error()).
> 
> Should we be calling bpstat_do_actions before that error()?

It is traditional for an error generated by a command list
to cause an abort of the rest of the command list.

Someone once requested a mode switch that would suppress that, though.

Re: [RFA/testsuite] test hand function call in commands list

[Daniel Jacobowitz]

On Mon, Apr 14, 2003 at 11:40:48AM -0400, Joel Brobecker wrote:
> The attached patch to break.exp was written by Klee Dienes and
> submitted in the following message:
> 
>         http://sources.redhat.com/ml/gdb-patches/2002-10/msg00586.html
> 
> The purpose of the test is to make sure that a problem occuring with
> function calls inside a commands list does not cause a SIGSEGV.
> 
> 2003-04-14  J. Brobecker  <brobecker@gnat.com>
> 
>         From Klee Dienne <kdienes@apple.com>
>         * gdb.base/break.exp: Add multiple calls to the inferior in
>         the user-commands for 'break 79'. Add a check for the calls
>         to the inferior in the check for the result. Add new test, to
>         check that user-defined breakpoint commands are called for functions
>         called by the user (currently fails).
> 
> When I ran the test, I was very surprised to see one FAIL. I am
> describing below the symptoms (no time to investigate this today), but I
> think the test is worthwhile adding anyway. Ok to apply?

This patch got sidetracked in a discussion of the one FAIL.  Since
it seems that the "failure" isn't something broken in GDB, but rather a
behavioral decision, I'd rather not add that part of the test.

I was going to separate out and apply the remainder of the patch, but
it's not acceptable - it tries to match inferior output directly, which
will fail for remote testing.  If someone wants to rewrite this test to
call inferior functions that set variables, and then print the
variables to verify that the functions were called, that'd be great. 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer