From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20622 invoked by alias); 29 Nov 2011 22:02:52 -0000 Received: (qmail 20610 invoked by uid 22791); 29 Nov 2011 22:02:51 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Nov 2011 22:02:17 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pATM2D1b011868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Nov 2011 17:02:13 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pATM2DDq006464; Tue, 29 Nov 2011 17:02:13 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pATM2BrN024120; Tue, 29 Nov 2011 17:02:11 -0500 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFC/WIP PATCH 09/14] I/T set support for breakpoints - trigger set, and stop set References: <20111128153742.17761.21459.stgit@localhost6.localdomain6> <20111128153942.17761.96028.stgit@localhost6.localdomain6> Date: Tue, 29 Nov 2011 22:02:00 -0000 In-Reply-To: <20111128153942.17761.96028.stgit@localhost6.localdomain6> (Pedro Alves's message of "Mon, 28 Nov 2011 15:39:42 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-11/txt/msg00834.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> This adds support for setting a breakpoint that only triggers on a Pedro> given set (a superset of the current thread specific breakpoints Pedro> support). In addition, it adds support for specifying the set of Pedro> threads that are suspended when the breakpoint is triggered. Pedro> Breakpoints need two sets. The trigger set, which is a generalization Pedro> of the "break foo thread N", meaning the set of inferiors/threads Pedro> where the breakpoint should fire, and, a suspend/stop set, which is Pedro> the set of inferiors/threads that should be suspended when the Pedro> breakpoint fires. What happens if the user types: [1.*] break function thread 3 How about something contradictory like [.2] break function thread 3 Pedro> The trigger set of breakpoints is set from the current set at the time Pedro> the breakpoint is created. The stop set is passed explicitly as Pedro> optional switch. E.g.,: Pedro> [TRIGGER-SET] break [-stop [STOP-SET]] LINESPEC Pedro> This leaves LINESPEC last, so that we can keep supporting the current Pedro> form, but avoid more hacks in linespecs like the special termination Pedro> for "thread/task/if" in the lexers --- that wouldn't work for `['. Looks good to me. Overdue, even :-) Pedro> and, the stop set is inferred from the "set non-stop" global option. Pedro> If non-stop is on, only the thread that triggers the breakpoint should Pedro> be suspended; if non-stop is off, then all threads will be suspended Pedro> when the breakpoint fires. It seems to me that the stop set has to be a superset of the trigger set. Otherwise you get into a funny situation where a thread hits a breakpoint, causing only other threads to stop. Or maybe this is intentional? I can't picture a use for it myself, though. Anyway, if this is a requirement, I think it should be enforced. Pedro> +static int Pedro> +bpstat_check_trigger_set (const struct breakpoint *b, struct thread_info *thread) Pedro> +{ Pedro> + if (b->trigger_set == NULL) Pedro> + return 1; Pedro> + Pedro> + if (itset_contains_thread (b->trigger_set, thread)) Pedro> + return 1; Pedro> + Pedro> + return 0; Delightfully simple. A couple notes though... First, I've been thinking we should probably make breakpoint re-setting more fine-grained. The idea would be to classify the events that current cause a re-set, giving them separate APIs in breakpoint.c, so that we can make re-setting more efficient. E.g., a new inferior should not cause a breakpoint to reset if the breakpoint cannot possibly match that inferior. I'm just trolling for your reaction to this. Second, a while back on gdb@ there was some talk of pushing thread-specific breakpoints to the target. This still seems like a good idea to me. I just wonder how this would interact with trigger sets, which are fairly general and which can depend on information known only to gdb, like the inferior numbering. I suppose one answer is, "use the 'thread' syntax for that". Tom