From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22012 invoked by alias); 10 Sep 2010 21:56:37 -0000 Received: (qmail 21983 invoked by uid 22791); 10 Sep 2010 21:56:35 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,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; Fri, 10 Sep 2010 21:56:30 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8ALuSIN005849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Sep 2010 17:56:28 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o8ALuRi3006894; Fri, 10 Sep 2010 17:56:28 -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 o8ALuRcQ023515; Fri, 10 Sep 2010 17:56:27 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 005803792BD; Fri, 10 Sep 2010 15:56:26 -0600 (MDT) From: Tom Tromey To: GDB Development Subject: Re: multi-{inferior,exec} References: Date: Fri, 10 Sep 2010 21:56:00 -0000 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/msg00069.txt.bz2 Tom> I think the next missing bit is support for I/T sets. Some updates on this... Tom> I think we can add an I/T set specifier before the linespec Tom> argument to "break". (I couldn't think of other commands that use Tom> linespecs that would need this...) It seems to make sense for the other "catch" commands, though those don't all use linespecs. Maybe it still makes sense to have the I/T set as an argument to the command (as opposed to a prefix or a "select" command), maybe not. Your comments appreciated. Tom> (gdb) break [*] collect_args Pedro pointed out that this could have an MI problem. Currently, a breakpoint is defined as having a single source location (as opposed to address locations) -- but this kind of breakpoint might have multiple locations, one per inferior. I was curious to see what we emit when a breakpoint has multiple addresses. Here's the CLI output from a gdb test case: (gdb) info b Num Type Disp Enb Address What 1 breakpoint keep y 1.1 y 0x08048447 in foo(int) at ../../../archer/gdb/testsuite/gdb.cp/mb-inline.h:26 1.2 y 0x080484a7 in foo(int) at ../../../archer/gdb/testsuite/gdb.cp/mb-inline.h:26 Here is the relevant MI: bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="",times="0",original-location="mb-inline.h:26"} This seems a little weird to me in a couple of ways. First, addr="" is strange, in that it seems to me that an attribute would be friendlier. This text is also undocumented ... but I presume that in practice MI clients must interpret this? (I further suppose the same applies to ".) Second, the various locations are not represented at all. Third, compare with an ordinary breakpoint: bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x08048487",func="main()",file="../../../archer/gdb/testsuite/gdb.cp/mb-inline1.cc",fullname="/home/tromey/gnu/archer/archer/gdb/testsuite/gdb.cp/mb-inline1.cc",line="32",times="0",original-location="main"} Here we get func, file, fullname, and line -- but with a breakpoint, we do not. So, since the current situation doesn't seem all that friendly to begin with, maybe extending it a little for this new use won't be so hard. Also, it occurred to me that an MI client would have to explicitly request such a breakpoint with an I/T set -- so maybe it is even ok to emit something different automatically. One partly-compatible idea would be to treat each location as a separate breakpoint, for the purposes of MI output. (This isn't totally compatible because some options are per-breakpoint and not per-location.) Then, we could provide a new option (and corresponding token in the -list-features output) to enable "real" output. The real form would show all the sub-locations of a master breakpoint. This approach would also let us fix PR 11657 in a straightforward way. Pedro and I talked a bit today about some specific use cases. First, it seems most likely that a front end will typically request a file:line breakpoint using an absolute path. That is, the user sees some source code and clicks on it. Here, the FE would send the MI equivalent of: break [*] file:line This will do the right thing: break in any inferior reaching that source line. Another use case would be putting a breakpoint on a particular function, say from some kind of symbol view. After some reflection, I think the solution in this case lies in a linespec extension, not in I/T sets. In particular: break [*] #libsomething.so#function I also looked into another idea we discussed -- having a kind of meta-breakpoint for I/T sets that sets new concrete breakpoints when the appropriate events occur. This means associating new metadata with a new kind of breakpoint and coming up with a new command name. This seems like more work, for a result that is not as nice to use. Tom