From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: continuations and breakpoint commands
Date: Wed, 30 Apr 2008 05:59:00 -0000 [thread overview]
Message-ID: <200804292221.52239.pedro@codesourcery.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
This patch fixes continuation handling in async mode, by making
the handling sequence match the sync code path.
Exec commands sequence should be:
execute command -> wait for stop -> rest of command
After that, if the stop was due to a breakpoint, we check for
any breakpoint commands associated with it. Any command is
allowed, so it's possible that one command be another exec
command, which resumes the target:
break main
commands
continue
end
execute command
-> wait for stop
-> rest of command
-> breakpoint commands
execute command -> ...
breakpoint commands used to be ran in the
command_line_handler_continuation. Now they're ran before
the continuations, which is wrong. If the continuation
has to pull a breakpoint out of the inferior, and a breakpoint
command resumed the inferior, the removal will fail (on targets
where writing inferior memory on a running target is not
possible, like linux).
Looking at top.c to copy the exact sync sequence also shows that
any language change is printed before running breakpoint commands.
This patch applies on top of this one:
[RFA] bpstat_do_actions in one place
http://sourceware.org/ml/gdb-patches/2008-04/msg00557.html
This fixes commands.exp failures. There's one case where the
removing a breakpoint from a running target was triggering, due
to a breakpoint command.
Tested on i686-pc-linux-gnu/async.
Ok, after the dependencies are in?
--
Pedro Alves
[-- Attachment #2: fix_commands.exp.diff --]
[-- Type: text/x-diff, Size: 2443 bytes --]
2008-04-29 Pedro Alves <pedro@codesourcery.com>
* inf-loop.c (inferior_event_handler): Run all continuations and
print any language change before running the breakpoint commands.
---
gdb/inf-loop.c | 33 +++++++++++++++++++--------------
1 file changed, 19 insertions(+), 14 deletions(-)
Index: src/gdb/inf-loop.c
===================================================================
--- src.orig/gdb/inf-loop.c 2008-04-29 20:45:35.000000000 +0100
+++ src/gdb/inf-loop.c 2008-04-29 22:04:03.000000000 +0100
@@ -92,30 +92,35 @@ inferior_event_handler (enum inferior_ev
was_sync = sync_execution;
async_enable_stdin ();
- /* If there's an error doing breakpoint commands, we don't
- want to throw -- continuation might still do something. */
- TRY_CATCH (e, RETURN_MASK_ERROR)
- {
- bpstat_do_actions (&stop_bpstat);
- }
/* If we were doing a multi-step (eg: step n, next n), but it
got interrupted by a breakpoint, still do the pending
continuations. The continuation itself is responsible for
- distinguishing the cases. */
+ distinguishing the cases. The continuations are allowed to
+ touch the inferior memory, e.g. to remove breakpoints, so run
+ them before running breakpoint commands, which may resume the
+ target. */
do_all_intermediate_continuations (0);
+ /* Always finish the previous command before running any
+ breakpoint commands. Any stop cancels the previous command.
+ E.g. a "finish" or "step-n" command interrupted by an
+ unrelated breakpoint is canceled. */
do_all_continuations (0);
- if (current_language != expected_language)
+ if (current_language != expected_language
+ && language_mode == language_mode_auto)
+ language_info (1); /* Print what changed. */
+
+ /* Don't propagate breakpoint commands errors. Either we're
+ stopping or some command resumes the inferior. The user will
+ be informed. */
+ TRY_CATCH (e, RETURN_MASK_ERROR)
{
- if (language_mode == language_mode_auto)
- {
- language_info (1); /* Print what changed. */
- }
+ bpstat_do_actions (&stop_bpstat);
}
- /* If the continuation did not start the target again,
- prepare for interation with the user. */
+ /* If no breakpoint command resumed the inferior, prepare for
+ interation with the user. */
if (!target_executing)
{
if (was_sync)
next reply other threads:[~2008-04-29 21:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-30 5:59 Pedro Alves [this message]
2008-04-30 14:03 ` Luis Machado
2008-04-30 14:21 ` Pedro Alves
2008-04-30 17:00 ` Pierre Muller
2008-04-30 18:25 ` Pedro Alves
2008-05-02 15:38 ` Daniel Jacobowitz
2008-05-04 22:49 ` Pedro Alves
2008-05-02 15:44 ` Daniel Jacobowitz
2008-05-07 4:33 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200804292221.52239.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox