From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15836 invoked by alias); 19 Jan 2011 18:48:33 -0000 Received: (qmail 15796 invoked by uid 22791); 19 Jan 2011 18:48:31 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate7.uk.ibm.com (HELO mtagate7.uk.ibm.com) (194.196.100.167) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Jan 2011 18:48:24 +0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p0JImMug013494 for ; Wed, 19 Jan 2011 18:48:22 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0JImOG41425528 for ; Wed, 19 Jan 2011 18:48:24 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0JImLV5016110 for ; Wed, 19 Jan 2011 11:48:21 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p0JImKuL015762; Wed, 19 Jan 2011 11:48:20 -0700 Message-Id: <201101191848.p0JImKuL015762@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 19 Jan 2011 19:48:20 +0100 Subject: Re: [rfc][2/2] Signal delivery + software single-step is broken To: pedro@codesourcery.com (Pedro Alves) Date: Wed, 19 Jan 2011 18:57:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <201101191124.25977.pedro@codesourcery.com> from "Pedro Alves" at Jan 19, 2011 11:24:25 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2011-01/txt/msg00403.txt.bz2 Pedro Alves wrote: > On Wednesday 19 January 2011 09:42:49, Ulrich Weigand wrote: > > The patch below changes linux_nat_wait_1 to actually look at the stepping > > status of the thread directly, instead of relying on the "step" flag. > > This means the "currently_stepping" routine has to be exported from > > infrun.c so it can be called here. > > I'm not objecting, but I'm curious on whether you've thought about how > the same problem would be solved in gdbserver/linux-low.c, which > can't call currently_stepping, since it's running in a different process? Good point, however this test already must use information only available in GDB itself, namely whether or not the signal is to be passed to the inferior or intercepted by GDB: if (!lp->step && inf->control.stop_soon == NO_STOP_QUIETLY && signal_stop_state (signo) == 0 && signal_print_state (signo) == 0 && signal_pass_state (signo) == 1) (The "stop_soon" state likewise is GDB private data.) Presumably because of this, gdbserver today does not appear to be implementing this particular optimization at all, but always reports all signals back to GDB to decide what to do with them. > One way to do it would be to do: > > QPassSignals: > vCont;c > QPassSignals:foo;bar > > but that is a lot of extra roundtrips, and not really (inferior) threadsafe in > non-stop mode. I agree that this would probably be the way to go about it. I'm not sure thread safety is really a concern here, given that we're talking about an optimization. If the implementation is conservative in the right direction, the worst thing that could happen is that a signal is reported that might have gotten short-circuited .. Similarly, the number of roundtrips could probably be reduced by only sending a QPassSignals when the list of interesting signal changes. For example, once we start single-stepping, we'd once send the QPassSignals: and then not send and further QPassSignals until we go back to letting the inferior continue freely. (And even then, we might further delay sending of the QPassSignals until such time as we notice we're actually seeing many to-be-passed signals being delivered to GDB, at which point switching on the optimization is actually worthwhile.) > It sounds like we'd need to tweak the target resume interface to be > able to say "continue, but I'm interested in signals and everything else", > or, "I'm telling you to continue, but you're really single-stepping", > like a new vCont;cs or some such? I'm not so sure I like this, as it introduces somewhat less well- defined semantics: what does "*really* single-stepping" mean, other than in terms of doing whatever it is GDB does now ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com