From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115124 invoked by alias); 5 Jun 2015 09:37:29 -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 115083 invoked by uid 89); 5 Jun 2015 09:37:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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; Fri, 05 Jun 2015 09:37:28 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id F0A4836B4EB; Fri, 5 Jun 2015 09:37:26 +0000 (UTC) Received: from blade.nx (ovpn-116-63.ams2.redhat.com [10.36.116.63]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t559bPXq015507; Fri, 5 Jun 2015 05:37:26 -0400 Received: by blade.nx (Postfix, from userid 1000) id 0E9D826231E; Fri, 5 Jun 2015 10:37:24 +0100 (BST) Date: Fri, 05 Jun 2015 09:37:00 -0000 From: Gary Benson To: Don Breazeal Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Make only user-specified executable filenames sticky Message-ID: <20150605093724.GA26604@blade.nx> References: <20150505151448.GA1417@blade.nx> <1430907977-30605-1-git-send-email-gbenson@redhat.com> <5550E357.9040209@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5550E357.9040209@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00079.txt.bz2 Don Breazeal wrote: > On 5/6/2015 3:26 AM, Gary Benson wrote: > > In GDB some executable files are supplied by the user (e.g. using > > a "file" command) and some are determined by GDB (e.g. while > > processing an "attach" command). GDB will not attempt to > > determine a filename if one has been set. This causes problems if > > you attach to one process and then attach to another: GDB will not > > attempt to discover the main executable on the second attach. If > > the two processes have different main executable files then the > > symbols will now be wrong. > > > > 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 realize that I am coming late to this discussion, sorry about > that. Likewise, sorry for taking so long to reply :) > How does this interact with follow-exec-mode? If follow-exec-mode > is 'new' and the program execs, then 'run' will use the original > executable file. But if follow-exec-mode is 'same' and the program > execs, then 'run' will use the executable file that was active after > the exec call. > > In the follow-exec-mode == 'same' instance, is the assumption that > the exec'd executable file takes on the same 'user-supplied' > attribute as the initial executable, since it is using the original > inferior? > > If so, is there a scenario where: > * the user supplies the exec file name > * the program execs, so the exec file name is now different > * then the user tries to do an attach (without an exec file name) to a > process running the original exec file, and gets the wrong exec file name? I'm not sure. Where would I need to look to check this out? (Where is the bit that updates the filename after exec?) Cheers, Gary -- http://gbenson.net/