Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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)

             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