From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93272 invoked by alias); 13 May 2015 08:39:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 93262 invoked by uid 89); 13 May 2015 08:39:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 13 May 2015 08:39:23 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4D8dJc9018343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 13 May 2015 04:39:19 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4D8dGlV026970; Wed, 13 May 2015 04:39:17 -0400 Message-ID: <55530DB4.3040608@redhat.com> Date: Wed, 13 May 2015 08:39:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Doug Evans CC: Gary Benson , gdb-patches , Philippe Waroquiers Subject: Re: [PATCH] Make only user-specified executable filenames sticky References: <20150505151448.GA1417@blade.nx> <1430907977-30605-1-git-send-email-gbenson@redhat.com> <5551D7AD.8080500@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00298.txt.bz2 On 05/12/2015 05:03 PM, Doug Evans wrote: > On Tue, May 12, 2015 at 3:36 AM, Pedro Alves wrote: >> Another way to handle that would be to leave the file loaded >> in inferior 1, and switch to a new inferior to investigate >> the other process. > > Sorry, these things don't always occur to me before I hit Send. > > Switching to a new inferior is three steps. > (gdb) add-inf > (gdb) infer 2 > (gdb) attach PID > > IWBN to have something like the following > > (gdb) attach -n PID # "n" for "in new inferior" I agree here. It's actually one thing that has been crossing my mind recently. I've been experimenting a lot with gdb's CLI around multi-thread and multi-inferior things, in context of i/t sets (see [1]), and making it possible to have "attach" create new inferiors would help. E.g., attaching to more than one process would be nice, like "attach PID1 PID2" and "attach --all-children PID". Maybe even make "attach PID" automatically decide to reuse the same inferior, so that gdb; attach" reuses inferior 1, but if you've already used inferior 1, "attach" creates another one. We do something like that when "target extended-remote" finds multiple processes already running on the server side. For preparing a new inferior for "run", we have "add-inferior -exec FILE", though maybe "file -n" would be nicer. [1] https://github.com/palves/gdb/commits/palves/itsets-wip-width (note: very experimental, not ready for general feedback yet) > > I kinda would rather do it differently, because it's more than > just "attach" where one would like to do something in a new inferior, > and IWBN to solve them all with one new command (or extension > of existing command). E.g., "new-inferior ", as in > "new-inferior attach PID". Or some such. Guess that could be the existing "add-inferior", as in "add-inferior -exec PROG attach PID". Not really sure I like that direction though. Seems less convenient and more prone to have users forget/miss this usage than teaching "attach" etc. directly to me. In an i/t sets world, another option would be for commands that create new inferiors to set the current focus to the just created inferior(s). Then the following commands would simply apply to the new inferiors. > > OTOH, "new-inferior pwd" doesn't make much sense, > and "attach -n PID" is simple (we'd want to enumerate > all such commands and make sure the same option letter is > available for use in all of them). Yeah. Thanks, Pedro Alves