From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24656 invoked by alias); 25 Oct 2006 21:24:52 -0000 Received: (qmail 24647 invoked by uid 22791); 25 Oct 2006 21:24:52 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 25 Oct 2006 21:24:43 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GcqEr-0000CS-9w for gdb@sourceware.org; Wed, 25 Oct 2006 17:24:41 -0400 Date: Wed, 25 Oct 2006 21:24:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: [rfc/remote] Tell remote stubs which signals are boring Message-ID: <20061025212441.GA622@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00247.txt.bz2 Some time ago, I got a bug report that gdbserver couldn't be used to debug a program. You'd tell it to "continue", and it wouldn't - it would just spin in place. We realized eventually that the problem was SIGALRM. There was a tiny signal handler running every timer tick (at about 100Hz, if I remember right). That's plenty of time for native GDB to notice, resume, and let the code run. But if you have to stop the program, including any threads, and send a packet over a socket to another machine, only to have GDB tell you that you're not interested in it anyway, then you never make any progress. By the time the program returns from its signal handler, SIGALRM is pending again. This is the solution I came up with for that problem, adjusted to HEAD and given a more sensible packet name. I have a tested implementation of this patch for HEAD, if my remote protocol choices are acceptable. The new mechanism is completely transparent to the user. All comments welcome! `QPassSignals SIGNAL [;SIGNAL]...' Each listed SIGNAL, using the same signal numbering used in continue packets and stop responses, should be passed directly to the inferior process. Each SIGNAL list item should be strictly greater than the previous item. These signals do not need to stop the inferior, or be reported to GDB. All other signals should be reported to GDB. Multiple `QPassSignals' packets do not combine; any earlier `QPassSignals' list is completely replaced by the new list. This packet improves performance when using `handle SIGNAL nostop noprint pass'. Reply: `OK' The request succeeded. `E NN' An error occurred. NN are hex digits. `' An empty reply indicates that `QPassSignals' is not supported by the stub. Use of this packet is controlled by the `set remote pass-signals' command (*note set remote pass-signals: Remote configuration.). This packet is not probed by default; the remote stub must request it, by supplying an appropriate `qSupported' response (*note qSupported::). -- Daniel Jacobowitz CodeSourcery