From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21847 invoked by alias); 26 Oct 2006 15:27:27 -0000 Received: (qmail 21839 invoked by uid 22791); 26 Oct 2006 15:27:27 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-vbr17.xs4all.nl (HELO smtp-vbr17.xs4all.nl) (194.109.24.37) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Oct 2006 15:27:18 +0000 Received: from webmail.xs4all.nl (dovemail5.xs4all.nl [194.109.26.7]) by smtp-vbr17.xs4all.nl (8.13.8/8.13.8) with ESMTP id k9QFRAPo012244; Thu, 26 Oct 2006 17:27:10 +0200 (CEST) (envelope-from mark.kettenis@xs4all.nl) Received: from 192.87.1.22 (SquirrelMail authenticated user sibelius) by webmail.xs4all.nl with HTTP; Thu, 26 Oct 2006 17:27:11 +0200 (CEST) Message-ID: <13276.192.87.1.22.1161876431.squirrel@webmail.xs4all.nl> In-Reply-To: <20061026121838.GA28927@nevyn.them.org> References: <20061025212441.GA622@nevyn.them.org> <453FEB98.8090202@avtrex.com> <20061026014027.GA9023@nevyn.them.org> <20061026121838.GA28927@nevyn.them.org> Date: Thu, 26 Oct 2006 15:27:00 -0000 Subject: Re: [rfc/remote] Tell remote stubs which signals are boring From: "Mark Kettenis" To: "Eli Zaretskii" , gdb@sourceware.org, ddaney@avtrex.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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/msg00266.txt.bz2 > On Thu, Oct 26, 2006 at 02:57:29AM -0400, Eli Zaretskii wrote: > > > Date: Wed, 25 Oct 2006 17:24:41 -0400 > > > From: Daniel Jacobowitz > > > > > > 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. > > > > I'm confused: shouldn't this packet be automatically sent to a remote > > target when I say, e.g., "handle SIGALRM nostop noprint pass"? Am I > > missing something? > > Now I'm confused :-) Isn't that exactly what I said above? It's > completely transparent; it just works. Perhaps I should even add more confusing statements to that. What if I say "handle SIGALRM nostop noprint pass" after I've connected to the remote target. Will it send a new QPassSignals packet when I do that? AFAICT from your patch it doesn't do that, and that seems broken to me.