From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6857 invoked by alias); 3 Nov 2011 21:01:54 -0000 Received: (qmail 6845 invoked by uid 22791); 3 Nov 2011 21:01:53 -0000 X-SWARE-Spam-Status: No, hits=-7.5 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; Thu, 03 Nov 2011 21:01:36 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA3L1Y9Q016457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2011 17:01:34 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pA3L1X8i021338; Thu, 3 Nov 2011 17:01:34 -0400 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 pA3L1Wx9026500; Thu, 3 Nov 2011 17:01:33 -0400 From: Tom Tromey To: Stan Shebs Cc: gdb@sourceware.org Subject: Re: Toward multicore GDB - Set theory References: <4EB088E7.8040107@earthlink.net> Date: Thu, 03 Nov 2011 21:01:00 -0000 In-Reply-To: <4EB088E7.8040107@earthlink.net> (Stan Shebs's message of "Tue, 01 Nov 2011 17:03:51 -0700") 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-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/msg00016.txt.bz2 >>>>> "Stan" == Stan Shebs writes: Stan> We then use set notation interesting with commands: Stan> (gdb) [.7-80] print mytlsglob Stan> $45 = [.8,16,32,64] 0xbadbad ; [.*] 0xfeedface Stan> shows most threads with the same value for a variable, and a handful Stan> of threads with a different value. This is a tricky example since it implies pushing a lot of smarts into 'print'. I'm in favor of it, I think it is the only way for this to make sense and scale -- just painful. Stan> Similarly, the single-thread option for breakpoints will be Stan> generalized to sets. Yes, nice. I have actually been considering doing this myself, as a follow-on to the ambiguous linespec patch. Stan> The astute reader will notice many holes. In particular, I am not Stan> giving a formal definition of set syntax and how it fits into the CLI, Stan> because I want us to develop some consensus on what would work best. Stan> Key decisions to be made are: Stan> 1) square brackets? curly brackets? nothing at all? Stan> 2) prefix? postfix? both? Stan> 3) build in extensibility? or leave to Python somehow? Stan> 4) is there a better term than ptc set? 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 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" Allowing the definition of new kinds of ptc keywords from Python seems natural. I guess the question is whether it would be performant enough. I think it would make sense to hold off on that, but carefully define the PTC set syntax to be extensible and write the code to conservatively reject unrecognized constructs. Then we have leeway to make additions in the future. Tom