From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6540 invoked by alias); 3 Sep 2010 22:41:07 -0000 Received: (qmail 6531 invoked by uid 22791); 3 Sep 2010 22:41:06 -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; Fri, 03 Sep 2010 22:40:58 +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.13.8/8.13.8) with ESMTP id o83MevxZ003303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Sep 2010 18:40:57 -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 o83MetWS027937; Fri, 3 Sep 2010 18:40:55 -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 o83Mesrb009318; Fri, 3 Sep 2010 18:40:54 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 148E7379832; Fri, 3 Sep 2010 16:40:53 -0600 (MDT) From: Tom Tromey To: GDB Development Subject: multi-{inferior,exec} Date: Fri, 03 Sep 2010 22:41:00 -0000 Message-ID: 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/msg00016.txt.bz2 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. First, the original spec: http://sourceware.org/ml/gdb/2008-08/msg00169.html Also relevant: http://sourceware.org/gdb/wiki/MultiProcess One concrete thing I plan to do is make objfiles not be relocated, basically following the idea here: http://sourceware.org/ml/gdb-patches/2009-06/msg00668.html This is mostly plumbing, but important for efficiency. 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 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. 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". 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 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. 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. There are more tasks beyond those, but I think those will hold me for a while. The remaining big things I am aware of (thanks Pedro) are: * Model follow-fork|vfork|exec in remote protocol + remote.c + gdbserver * gdbserver needs work for multi-inferior + multi-arch Maybe we need a target description per inferior here. Tom