public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: QPassSignals in non-stop mode
Date: Mon, 03 May 2010 02:15:00 -0000	[thread overview]
Message-ID: <201005030315.22774.pedro@codesourcery.com> (raw)

I've applied this patch.

I just noticed that "handle SIGFOO pass/nopass what/whatnot"
wasn't immediately informing the remote end of what is the
new set of signals it can silently pass to the inferior without
informing gdb.  Currently, we only do that on resume, which is
only good enough for all-stop.  In non-stop, if threads are
running, I don't want to wait for the next resume (explicitly
requested, or, due to an internal event handling) to make it
effective.

Fortunatelly, we already have a target_ops method for this,
called from within the "handle" command, whenever the
signals pass/stop/print states changes.

-- 
Pedro Alves

2010-05-03  Pedro Alves  <pedro@codesourcery.com>

	gdb/
	* remote.c (remote_notice_signals): New.
	(remote_start_remote): In non-stop mode, update the remote end on
	which signals it can silently pass.
	(init_remote_ops): Install remote_notice_signals.

---
 gdb/remote.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

Index: src/gdb/remote.c
===================================================================
--- src.orig/gdb/remote.c	2010-05-03 02:50:12.000000000 +0100
+++ src/gdb/remote.c	2010-05-03 02:50:15.000000000 +0100
@@ -1535,6 +1535,14 @@ remote_pass_signals (void)
     }
 }
 
+static void
+remote_notice_signals (ptid_t ptid)
+{
+  /* Update the remote on signals to silently pass, if they've
+     changed.  */
+  remote_pass_signals ();
+}
+
 /* If PTID is MAGIC_NULL_PTID, don't set any thread.  If PTID is
    MINUS_ONE_PTID, set the thread to -1, so the stub returns the
    thread.  If GEN is set, set the general thread, if not, then set
@@ -3155,6 +3163,11 @@ remote_start_remote (struct ui_out *uiou
       /* In non-stop mode, any cached wait status will be stored in
 	 the stop reply queue.  */
       gdb_assert (wait_status == NULL);
+
+      /* Update the remote on signals to silently pass, or more
+	 importantly, which to not ignore, in case a previous session
+	 had set some different set of signals to be ignored.  */
+      remote_pass_signals ();
     }
 
   /* If we connected to a live target, do some additional setup.  */
@@ -9898,6 +9911,7 @@ Specify the serial device it is connecte
   remote_ops.to_kill = remote_kill;
   remote_ops.to_load = generic_load;
   remote_ops.to_mourn_inferior = remote_mourn;
+  remote_ops.to_notice_signals = remote_notice_signals;
   remote_ops.to_thread_alive = remote_thread_alive;
   remote_ops.to_find_new_threads = remote_threads_info;
   remote_ops.to_pid_to_str = remote_pid_to_str;

                 reply	other threads:[~2010-05-03  2:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=201005030315.22774.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).