From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 594 invoked by alias); 3 May 2010 02:15:33 -0000 Received: (qmail 585 invoked by uid 22791); 3 May 2010 02:15:32 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 May 2010 02:15:28 +0000 Received: (qmail 1239 invoked from network); 3 May 2010 02:15:26 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 May 2010 02:15:26 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: QPassSignals in non-stop mode Date: Mon, 03 May 2010 02:15:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201005030315.22774.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00027.txt.bz2 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 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;