From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29711 invoked by alias); 25 Oct 2006 22:56:34 -0000 Received: (qmail 29702 invoked by uid 22791); 25 Oct 2006 22:56:33 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1.dnsmadeeasy.com (HELO smtp1.dnsmadeeasy.com) (205.234.170.134) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Oct 2006 22:56:30 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id E9902E73B4; Wed, 25 Oct 2006 18:56:25 -0400 (EDT) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Wed, 25 Oct 2006 18:56:25 -0400 (EDT) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 15:56:24 -0700 Message-ID: <453FEB98.8090202@avtrex.com> Date: Wed, 25 Oct 2006 22:56:00 -0000 From: David Daney User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sourceware.org Subject: Re: [rfc/remote] Tell remote stubs which signals are boring References: <20061025212441.GA622@nevyn.them.org> In-Reply-To: <20061025212441.GA622@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00249.txt.bz2 Daniel Jacobowitz wrote: > 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::). Does this mean that you have to issue a 'set remote pass-signals' command, or is it done automatically for 'handle noprint nostop pass' if the remote stub supports it? Not being that familiar with the remote protocol, it is unclear to me. David Daney