From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31251 invoked by alias); 24 Mar 2011 15:50:41 -0000 Received: (qmail 31242 invoked by uid 22791); 24 Mar 2011 15:50:40 -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 mtagate6.uk.ibm.com (HELO mtagate6.uk.ibm.com) (194.196.100.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Mar 2011 15:50:34 +0000 Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate6.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p2OFoORL018612 for ; Thu, 24 Mar 2011 15:50:24 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2OFor992039832 for ; Thu, 24 Mar 2011 15:50:53 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 p2OFoOD6012773 for ; Thu, 24 Mar 2011 09:50:24 -0600 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 p2OFoNEt012695; Thu, 24 Mar 2011 09:50:23 -0600 Message-Id: <201103241550.p2OFoNEt012695@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 24 Mar 2011 16:50:23 +0100 Subject: Re: [rfc][rft (procfs, nto-procfs)] Fix signal bypass heuristic with software single-step To: pedro@codesourcery.com (Pedro Alves) Date: Thu, 24 Mar 2011 16:39:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <201103221618.21253.pedro@codesourcery.com> from "Pedro Alves" at Mar 22, 2011 04:18:21 PM 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-03/txt/msg01076.txt.bz2 Pedro Alves wrote: > As discussed before, I like the approach, but I have a couple of remarks > to the implementation: Thanks for the review! > - There are more calls to target_resume in infrun.c. Don't we need > to consider signals around those? Hmm, that's true. > - In non-stop, if you have this sequence: > > - step thread 1 > - continue thread 2 (imediately afterwards) > - thread 1 gets signal FOO (which is normally pass-able). > > when handling the latter event, since the "signal_pass" set is > global, and has been filled by the previous continue, the target > will think it doesn't need to report the signal back to core gdb. > > You've said before about this when I raised the issue before: > > "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 .." > > Might be we just need to check if _any_ thread is stepping, when > deciding whether to tell the target to report back all signals? Right, that seems correct to me. Tom Tromey wrote: > I would like it if there were more documentation about what this method > means and how it is used. Actually, I suppose I would prefer it on the > field in struct target_ops, to be read by people porting gdb. Good point, agreed. I'll work on another update of the patch ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com