From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26221 invoked by alias); 10 Sep 2010 22:52:32 -0000 Received: (qmail 26210 invoked by uid 22791); 10 Sep 2010 22:52:30 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Sep 2010 22:52:24 +0000 Received: (qmail 25530 invoked from network); 10 Sep 2010 22:52:22 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Sep 2010 22:52:22 -0000 Message-ID: <4C8AB69B.4010108@codesourcery.com> Date: Fri, 10 Sep 2010 22:52:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Tom Tromey CC: GDB Development Subject: Re: multi-{inferior,exec} References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00070.txt.bz2 Tom Tromey wrote: > I've been looking at multi-inferior/multi-exec the last few days. I > want to polish a few edges and make it work nicely on Linux. I thought > I'd post about what I think I am going to implement. > > [...] > > I think the next missing bit is support for I/T sets. E.g., I wanted to > try to debug g++ but put a breakpoint in its cc1plus subprocess. You > can do this today, but only clumsily: either by using add-inferior to > load the symbols for cc1plus, or by using "catch exec" and setting the > breakpoint at exec time. I/T sets would let users set this sort of > breakpoint more easily. > I/T sets are one of the bits that didn't make it from multiprocess-20081120-branch to the trunk. You can look at the branch's inferior.h and see the internal definition, which basically consists of a string that is the specification and a possibly-dynamic vector of inferiors computed from it. > I am not sure what is required to integrate I/T sets into inferior > control (something mentioned on the wiki page). If anyone (Pedro? > Stan?) has state to share, I'm happy to hear it. > Much of it is a matter of deciding what to iterate over, vs limiting to a single current inferior. For instance, using the prefix syntax I originally suggested, "[4-6] print x" should print three lines, add three elements to value history, etc. So one could imagine a generic i/t set iteration meta-command, but it's not clear that iteration is always the right thing to do, and maybe individual commands should somehow whether they are sensible for iteration. > I think we can add an I/T set specifier before the linespec argument to > "break". (I couldn't think of other commands that use linespecs that > would need this...) E.g., in the g++ scenario, this would set a > breakpoint that would be resolved in libcpp: > > (gdb) break [*] collect_args > > "[*]" is the I/T set representing "all current or future inferiors". > In my global breakpoint project ( http://sourceware.org/ml/gdb/2010-05/msg00019.html ), I've been using a "process" keyword where "thread" and "task" are used now. It doesn't win elegance points, but I think it corresponds better to how the user thinks - "OK, I'm breaking on collect_args, and oh yeah, I want to catch it in any process, not just the one I have now". I don't think it would hurt to support a couple syntax variations, there is not going to be much prior expectation to accommodate. > If no I/T set is specified, it would default to the current inferior. > > The original spec had a "focus" command... but that is already used by > the TUI. How did that get resolved? It seems to me that we could just > use "select" instead. > I changed TUI to use "ffocus", on the theory that there aren't many TUI users. "select" isn't great because completion is ambiguous with "select-frame". > I was thinking it would be nice to extend "thread apply" to take an I/T > set argument. Maybe "inferior apply" is a nicer way to spell it. > One advantage to prefix is that the '[' introduces the iteration desire succinctly. > I think maybe the I/T set syntax could be expanded or changed a little. > I'm at least thinking of "." as a synonym for "current inferior", and > being able to differentiate named sets and executables. > I added a few things beyond the original spec, but it's been so long I don't remember what. :-) Stan