From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9994 invoked by alias); 4 Nov 2011 13:20:25 -0000 Received: (qmail 9979 invoked by uid 22791); 4 Nov 2011 13:20:24 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_FC 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, 04 Nov 2011 13:20:10 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RMJgn-0000dV-6D from pedro_alves@mentor.com ; Fri, 04 Nov 2011 06:20:09 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2011 13:20:07 +0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Toward multicore GDB - Set theory Date: Fri, 04 Nov 2011 13:20:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-12-generic; KDE/4.7.2; x86_64; ; ) Cc: Tom Tromey , Stan Shebs References: <4EB088E7.8040107@earthlink.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111041320.05445.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00019.txt.bz2 On Thursday 03 November 2011 21:01:32, Tom Tromey wrote: > I think in the past we talked about square brackets and prefix. > How about we consider that as a straw proposal? > > (gdb) [0-13] print x Yes, I had actually prototyped that yesterday for breakpoints, and it was easy on top of a bunch of other infrustructure. (I made `[' a command). > I think that would suffice for all commands, even breakpoints; though it > may be slightly confusing that breakpoints "capture" the set while other > commands operate on them immediately. If that is too confusing then > breakpoints could do another syntax, eg: > > (gdb) break [0-13] function # "semi-prefix" > (gdb) break function thread [0-13] # "natural extension" Breakpoints need two sets. The trigger set, which is a generalization of the "break foo thread N", meaning the set of inferiors/threads where the breakpoint should fire, and, and suspend/stop set, which is the set of inferiors/threads that should be suspended when the breakpoint fires. The HPD "standard" suggests: [TRIGGER-SET] break {procedure | line | #file#line} [ {-count n | -if condition} ] [-stop {stop-set | "[]"} ] In my prototype I chose to make that (simplified) for GDB (`()''s means optional): [TRIGGER-SET] break -stop [STOP-SET] (--) LINESPEC That is, put LINESPEC last, so that we can keep supporting the current form, but avoid more hacks in linespecs like the special termination for "thread/task/if" in the lexers --- that wouldn't work for `['. If you don't specify a [TRIGGER-SET] explicitly, the trigger set should be the current global set. I have yet to specify how that exactly works, but it should be adjustable with a "focus ITSET" command (whatever the spelling), and supposedly the "thread" and "inferior" commands will affect the default set too in some way. So what I did was define the `[' command to temporarily override the current global set. I think that'll work for other commands too. Below's what I got now. (gdb) info threads Id Target Id Frame 3 Thread 0x7ffff7028700 (LWP 2296) "threads" (running) * 2 Thread 0x7ffff7829700 (LWP 2295) "threads" thread_function0 (arg=0x0) at threads.c:63 1 Thread 0x7ffff7fcb720 (LWP 2290) "threads" (running) (gdb) [.2] break -stop [.3] 63 Breakpoint 4 at 0x40076d: file threads.c, line 63. Trigger on thread 2 (equivalent to break 63 thread 2), and when the breakpoint fires, stop thread 3. Like so: (gdb) c -a& Continuing. (gdb) Breakpoint 4, thread_function0 (arg=0x0) at threads.c:63 63 (*myp) ++; info threads Id Target Id Frame 3 Thread 0x7ffff7028700 (LWP 2296) "threads" 0x00007ffff78d75ad in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6 * 2 Thread 0x7ffff7829700 (LWP 2295) "threads" thread_function0 (arg=0x0) at threads.c:63 1 Thread 0x7ffff7fcb720 (LWP 2290) "threads" (running) (gdb) info breakpoints Num Type Disp Enb Address What 4 breakpoint keep y 0x000000000040076d in thread_function0 at threads.c:63 stop only in trigger-set: [.2] suspend all in stop-set: [.3] breakpoint already hit 1 time We can make a breakpoint that stops the world with (recall I had non-stop on): (gdb) del 4 (gdb) [.2] break -stop [all] 63 Breakpoint 5 at 0x40076d: file threads.c, line 63. (gdb) c -a& Continuing. (gdb) Breakpoint 5, thread_function0 (arg=0x0) at threads.c:63 63 (*myp) ++; info threads Id Target Id Frame 3 Thread 0x7ffff7028700 (LWP 2296) "threads" 0x00007ffff78d75ad in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6 * 2 Thread 0x7ffff7829700 (LWP 2295) "threads" thread_function0 (arg=0x0) at threads.c:63 1 Thread 0x7ffff7fcb720 (LWP 2290) "threads" 0x00007ffff7bc606d in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 Since I've reimplemented all-stop on top of non-stop, when non-stop is off, not specifying a stop set (or specifying it as empty, like -stop []) means that all threads stop by default, e.g., `[.2] break 63', but you can still (with all-stop) specify a breakpoint that only suspends a given itset, with: (gdb) [.2] break -stop [.3] 63 Breakpoint 5 at 0x40076d: file threads.c, line 63. (gdb) c & Continuing. (gdb) Breakpoint 5, thread_function0 (arg=0x0) at threads.c:63 63 (*myp) ++; info threads Id Target Id Frame 3 Thread 0x7ffff7028700 (LWP 2645) "threads" 0x00007ffff78d75ad in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6 * 2 Thread 0x7ffff7829700 (LWP 2644) "threads" thread_function0 (arg=0x0) at threads.c:63 1 Thread 0x7ffff7fcb720 (LWP 2610) "threads" (running) So effectively, this ends up as a superset of all-stop/non-stop, with the non-stop setting controlling the default stop set. I haven't spent much time on the syntax bits yet (been focusing on run control infrustructure), so this is obviously not a fully cooked spec, but I'm mostly following the HPD spec anyway. :-) -- Pedro Alves