From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29600 invoked by alias); 25 Oct 2006 21:33:24 -0000 Received: (qmail 29579 invoked by uid 22791); 25 Oct 2006 21:33:22 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Oct 2006 21:33:18 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by brahms.sibelius.xs4all.nl (8.13.8/8.13.6) with ESMTP id k9PLWfop014926; Wed, 25 Oct 2006 23:32:42 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.8/8.13.6) with ESMTP id k9PLWfWQ005275; Wed, 25 Oct 2006 23:32:41 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id k9PLWfoY018957; Wed, 25 Oct 2006 23:32:41 +0200 (CEST) Date: Wed, 25 Oct 2006 21:33:00 -0000 Message-Id: <200610252132.k9PLWfoY018957@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb@sourceware.org In-reply-to: <20061025212441.GA622@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 25 Oct 2006 17:24:41 -0400) Subject: Re: [rfc/remote] Tell remote stubs which signals are boring References: <20061025212441.GA622@nevyn.them.org> 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/msg00248.txt.bz2 > Date: Wed, 25 Oct 2006 17:24:41 -0400 > From: Daniel Jacobowitz > > 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! Makes sense to me. There are native targets too that support something similar; on Solaris you can tell the kernel what signals you're interested in, and GDB will not even get the signals that are "nostop noprint pass". I hope someone who is more familiar with the remote protocol can say something sane about the syntax you chose for the QPassSignals packet. Mark