From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2491 invoked by alias); 11 Sep 2010 01:46:40 -0000 Received: (qmail 2481 invoked by uid 22791); 11 Sep 2010 01:46:38 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD 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; Sat, 11 Sep 2010 01:46:33 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8B1kOSN008150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Sep 2010 21:46:26 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o8B1kNBP029247; Fri, 10 Sep 2010 21:46:24 -0400 Received: from opsy.redhat.com (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 o8B1kMYk014737; Fri, 10 Sep 2010 21:46:23 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 9AC6A3792BD; Fri, 10 Sep 2010 19:46:22 -0600 (MDT) From: Tom Tromey To: Stan Shebs Cc: GDB Development Subject: Re: multi-{inferior,exec} References: <4C8ABA20.3010701@codesourcery.com> Date: Sat, 11 Sep 2010 01:46:00 -0000 In-Reply-To: <4C8ABA20.3010701@codesourcery.com> (Stan Shebs's message of "Fri, 10 Sep 2010 16:07:12 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2010-09/txt/msg00072.txt.bz2 >>>>> "Stan" == Stan Shebs writes: Stan> The '#' syntax is in the old spec actually, you even commented about Stan> it in http://sourceware.org/ml/gdb/2008-08/msg00177.html :-) Yeah. More or less I am working through rediscovering the reasons all those things were in the spec in the first place. >From the global breakpoint message, it looks like you are planning to tackle this in some way. I forgot about this part of your project, sorry about that. Tom> This means associating new metadata with a new kind of breakpoint and Tom> coming up with a new command name. This seems like more work, for a Tom> result that is not as nice to use. Stan> What I've been doing for now for global breakpoints is to add the Stan> quasi-i/t set as another attribute of a breakpoint, a la thread or Stan> cond_string. This then is both interpreted by GDB, for processes that Stan> are currently under GDB's control, and passed to a kernel module that Stan> is monitoring all other processes for hits. My initial patch was to replace the pspace field in breakpoint with an I/T set. This works fine, the problem is that it breaks the MI invariant of one source location per breakpoint. I think your approach probably won't have this problem, because (I assume) your global breakpoints are inherently objfile-specific. What kinds of specifications does the kernel module accept? If the kernel accepts something more limited than gdb, we could always just upload an approximation to an I/T set and let gdb filter out the ones it doesn't care about. FWIW, my current use case is very simple: start gdb on gcc, set a breakpoint that will be resolved in cc1, run. I think this is a pretty reasonable thing to want to do; for me it seems ok to require a little extra work (like adding "[*]" to the break command), but not a lot of extra work (like looking up the full path to cc1 to give to add-inferior). Maybe it would be ok for "break collect_args" to mean "break on the first instance of collect_args that is resolved anywhere, but now convert this to a breakpoint that only resolves to this particular function in this objfile. I don't know... it doesn't feel completely natural to me, but that isn't a very strong reason for anybody else to do anything :) Stan> I/T sets are one of the bits that didn't make it from Stan> multiprocess-20081120-branch to the trunk. I did look at this, but I ended up writing my own. You can see it here: http://sourceware.org/git/gitweb.cgi?p=archer.git;a=blob_plain;f=gdb/itset.h;hb=archer-tromey-multi-inferior http://sourceware.org/git/gitweb.cgi?p=archer.git;a=blob_plain;f=gdb/itset.c;hb=archer-tromey-multi-inferior Stan> In my global breakpoint project Stan> (http://sourceware.org/ml/gdb/2010-05/msg00019.html ), I've been Stan> using a "process" keyword where "thread" and "task" are used now. My first reaction to these kinds of extensions is caution, because they can introduce expression ambiguity. (I've sometimes considered adding ";" as an expression terminator to help with this...) Could you expand more on what you are planning? E.g., exactly what syntax you intend to support, how users will specify sets of processes, etc? I read your post and I see the PID range thing... is that the only way? That isn't ambiguous, but putting an I/T set here would be. Unless we changed the I/T set syntax (using {} would work). I guess I don't mind if we have multiple syntaxes, though it seems like if the I/T set syntax is flexible enough and simple enough, we could just use it everywhere. Maybe I should just wait until you and/or the UPC guys have everything finished :-). It sounds like we have substantial overlap. There's also a lot of overlap between your work and the ugdb project... we'll have some interesting discussions at the GCC Summit this year :-) Tom