From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72547 invoked by alias); 13 May 2015 07:55:08 -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 72530 invoked by uid 89); 13 May 2015 07:55:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 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 07:55:04 +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 t4D7sw5q010815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 13 May 2015 03:54:58 -0400 Received: from blade.nx (ovpn-116-110.ams2.redhat.com [10.36.116.110]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4D7svYx001713; Wed, 13 May 2015 03:54:57 -0400 Received: by blade.nx (Postfix, from userid 1000) id 94347263CAF; Wed, 13 May 2015 08:54:56 +0100 (BST) Date: Wed, 13 May 2015 07:55:00 -0000 From: Gary Benson To: Doug Evans Cc: Pedro Alves , gdb-patches , Philippe Waroquiers Subject: Re: [PATCH] Make only user-specified executable filenames sticky Message-ID: <20150513075456.GA3730@blade.nx> References: <20150505151448.GA1417@blade.nx> <1430907977-30605-1-git-send-email-gbenson@redhat.com> <5551D7AD.8080500@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00296.txt.bz2 Doug Evans wrote: > On Tue, May 12, 2015 at 3:36 AM, Pedro Alves wrote: > > On 05/11/2015 09:23 PM, Doug Evans wrote: > > > On Wed, May 6, 2015 at 3:26 AM, Gary Benson wrote: > > > > This commit updates GDB to keep track of which executable > > > > filenames were supplied by the user. When GDB might attempt > > > > to determine an executable filename and one is already set, > > > > filenames determined by GDB may be overridden but > > > > user-supplied filenames will not. > > > > > > I can imagine sometimes wanting either behaviour, depending on > > > the situation. > > > > Yeah, AFAICS, both examples you gave work the same before > > and after Gary's patch. > > > > > E.g., if I supply a file name do some stuff, and then change > > > my mind or wish to investigate a difference process I may > > > wish gdb to automagically pick up the file name of the new > > > process. > > > > In that case, one can use "file; attach PID". > > > > That is, you can just unload the previous program, so that GDB > > picks up the new one automatically on next attach. > > I realize one *could* do that. > Thing is, someone's muscle memory may make them expect > "attach PID" to Just Work. > After all, "bash$ gdb" + "(gdb) attach PID" Just Works. > > Plus that's two steps. > Why do I *have* to first type "file" with no arguments? > (Joe User may be thinking) > The difference in the two scenarios is explainable, but there's > still an incongruity here. > > We go to lengths to reduce typing in the CLI session. > IWBN if one could type, say, > "attach -f PID" (f for "force gdb to use the binary of the attached > process", or whatever). I asked already, but nobody answered, so... If you say "attach PID", and GDB can see that PID's executable is /foo/bar, and the current exec-file is not /foo/bar/, under what circumstances should GDB *not* automatically reload the new exec- file? i.e. why could this "attach -f" behavior not be the default? Cheers, Gary -- http://gbenson.net/