From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8916 invoked by alias); 19 Jan 2011 18:24:40 -0000 Received: (qmail 8907 invoked by uid 22791); 19 Jan 2011 18:24:38 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Jan 2011 18:24:34 +0000 Received: (qmail 11512 invoked from network); 19 Jan 2011 18:24:32 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Jan 2011 18:24:32 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [rfc][2/2] Signal delivery + software single-step is broken Date: Wed, 19 Jan 2011 18:48:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-24-generic; KDE/4.5.1; x86_64; ; ) Cc: "Ulrich Weigand" References: <201101191642.p0JGgntq023362@d06av02.portsmouth.uk.ibm.com> In-Reply-To: <201101191642.p0JGgntq023362@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101191124.25977.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00402.txt.bz2 On Wednesday 19 January 2011 09:42:49, Ulrich Weigand wrote: > even with the previous patch, some sigstep.exp tests are still failing. > This is due to a peculiarity of the linux-nat target, which sometimes > decides to *not* report a signal event to GDB's main event loop, but > simply re-dispatch the inferior directly. > > This is broken if GDB actually needs to handle signal delivery specially, > which is in particular the case if we're currently single-stepping. > Therefore, linux-nat refrains from such by-passing of the main event > loop if single-stepping is in progress. However, it does so by simply > checking the "step" flag that was passed to its resume implementation. > But this flag will always be zero on targets that do software single- > stepping -- but those also must not bypass signal delivery ... > > 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. > > Thoughts? 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? 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. 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? If we end up needing something like this, then we'd use the same interface for linux nat. -- Pedro Alves