From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31956 invoked by alias); 16 Dec 2011 19:24:37 -0000 Received: (qmail 31944 invoked by uid 22791); 16 Dec 2011 19:24:36 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_BJ X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Dec 2011 19:24:21 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RbdOF-0000KN-Tj from pedro_alves@mentor.com ; Fri, 16 Dec 2011 11:24:20 -0800 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Dec 2011 19:24:18 +0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC/WIP PATCH 09/14] I/T set support for breakpoints - trigger set, and stop set Date: Fri, 16 Dec 2011 19:29:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-13-generic; KDE/4.7.2; x86_64; ; ) Cc: Tom Tromey References: <20111128153742.17761.21459.stgit@localhost6.localdomain6> <20111128153942.17761.96028.stgit@localhost6.localdomain6> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112161924.12152.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-12/txt/msg00532.txt.bz2 On Tuesday 29 November 2011 22:02:11, Tom Tromey wrote: > >>>>> "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 The breakpoint triggers if the thread that hits it is both in [1.*], and is thread 3. > How about something contradictory like > > [.2] break function thread 3 Breakpoint never triggers. Given that the trigger set may well be a dynamic set, it seems futile to try to detect such cases. Just don't do it. > > 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. I've defined it such that the thread that triggered the breakpoint always stops, even if it is not in the stop set. That meant that and empty stop set is the same behavior as a breakpoint hit in non-stop mode. The alternative, and because we can't know upfront which thread will hit the breakpoint, is to have a special set for the thread that triggered (or more generaly, the current thread), e.g.: [all] break -stop [@] LINESPEC OTOH, `break -stop []' resuming the thread that hit the breakpoint make the breakpoint look like a tracepoint. Hmm. > > Or maybe this is intentional? I can't picture a use for it myself, > though. E.g., when the event handling thread triggers this breakpoint (an incoming event), stop everything in the DSP core. Or all in the inferior that sent the event. > 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. Yeah, we've talked about that in the context of the objfile sharing discussion, even IIRC. > 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. Well, the reaction is "yes". :-) > 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". Thread-specific breakpoints on the target would necessarily get the GDB thread number translated to the target thread number. The target never sees GDB thread numbers in any circunstance. Thread-specific breakpoints are already specified with the GDB generic thread number (break foo thread N). sets could be translated similarly. Even if the translation isn't 1-1, it's sufficient that the stop set as sent to the target is larger and includes the whole of the set specified by the user. E.g., say we only support passing down one thread id associated with a breakpoint. If the set is unambiguously for that thread, great, pass that thread id down to the target along with the breakpoint. If the breakpoint is set with a trigger set that includes e.g., two threads, threads 1 and 2 of inferior 1, select the next best target set that includes both of those threads. That'd be, planting the breakpoint on the process of inferior 1 only, but not in any other process, and have gdb transparently re-resume all other threads if they trip on the breakpoint, just like thread-specific breakpoints are handled today. -- Pedro Alves