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: Daniel Jacobowitz <drow at mvista dot com>
- To: Joel Brobecker <brobecker at gnat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 16 Apr 2003 10:23:21 -0400
- Subject: Re: [RFA/testsuite] test hand function call in commands list
- References: <20030414154048.GC1151@gnat.com>
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()?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer