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

[Michael Snyder <msnyder@redhat.com>]

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.