This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA/testsuite] test hand function call in commands list
- From: Michael Snyder <msnyder at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Joel Brobecker <brobecker at gnat dot com>, gdb-patches at sources dot redhat dot com
- Date: Tue, 22 Apr 2003 19:08:58 -0700
- Subject: Re: [RFA/testsuite] test hand function call in commands list
- Organization: Red Hat, Inc.
- References: <20030414154048.GC1151@gnat.com> <20030416142321.GA7612@nevyn.them.org>
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 at gnat dot com>
> >
> > From Klee Dienne <kdienes at apple dot 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.