From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10359 invoked by alias); 24 Jun 2013 20:50:39 -0000 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 Received: (qmail 10349 invoked by uid 89); 24 Jun 2013 20:50:39 -0000 X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 24 Jun 2013 20:50:38 +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 r5OKoa60015012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Jun 2013 16:50:36 -0400 Received: from barimba (ovpn-113-102.phx2.redhat.com [10.3.113.102]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r5OKoZqt001299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 16:50:35 -0400 From: Tom Tromey To: David Taylor Cc: gdb@sourceware.org Subject: Re: add-inferior / clone-inferior References: <7249.1369061005@usendtaylorx2l> <87bo84l5ad.fsf@fleche.redhat.com> Date: Mon, 24 Jun 2013 20:50:00 -0000 In-Reply-To: <87bo84l5ad.fsf@fleche.redhat.com> (Tom Tromey's message of "Tue, 21 May 2013 09:30:02 -0600") Message-ID: <878v1zutb9.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-06/txt/msg00054.txt.bz2 Tom> The whole target stack needs to be switched out depending on which Tom> target is "active". I guess one idea would be to make it depend on the Tom> current inferior. But then I would worry whether the correct inferior Tom> is always selected when gdb is doing various operations. Tom> I think I'd also examine all the calls to push_target, unpush_target, Tom> and target_is_pushed to make sure they are ok. I think there are hidden Tom> gotchas here. E.g., "record" will eventually call push_target via Tom> record_full_open -- which examines the current target stack and stores Tom> stuff into a global. I played with this a bit last week and again today. I have it working well enough that I can run one inferior while visiting a core file in another. I'll push my branch eventually; sooner if somebody wants to see it. Tom> I wonder if there are other UI issues to consider. Pedro pointed out a few on irc. They're in the notes on the branch. Tom> It would be very nice to have a wiki page for this project, with the Tom> plans and links. I'll set one up. Tom