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).