From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95567 invoked by alias); 3 Jul 2015 11:14:22 -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 95558 invoked by uid 89); 3 Jul 2015 11:14:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 03 Jul 2015 11:14:20 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 9C44EB8158; Fri, 3 Jul 2015 11:14:19 +0000 (UTC) Received: from blade.nx (ovpn-116-52.ams2.redhat.com [10.36.116.52]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t63BEIgl025594; Fri, 3 Jul 2015 07:14:19 -0400 Received: by blade.nx (Postfix, from userid 1000) id 5656E2643EF; Fri, 3 Jul 2015 12:14:18 +0100 (BST) Date: Fri, 03 Jul 2015 11:14:00 -0000 From: Gary Benson To: Don Breazeal Cc: "gdb-patches@sourceware.org" , Joel Brobecker Subject: Re: [PATCH] Make only user-specified executable filenames sticky Message-ID: <20150703111418.GB15448@blade.nx> References: <20150505151448.GA1417@blade.nx> <1430907977-30605-1-git-send-email-gbenson@redhat.com> <5550E357.9040209@codesourcery.com> <20150605093724.GA26604@blade.nx> <5571B828.1080208@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5571B828.1080208@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00094.txt.bz2 Don Breazeal wrote: > On 6/5/2015 2:37 AM, Gary Benson wrote: > > 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. > > > > > > 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?) > > I think it goes like this: infrun.c:follow_exec calls > exec.c:exec_file_attach, which updates the name of the executable. Ah, there is exactly the scenario you describe Don, good call. Joel, I can fix v3 of this patch to zero exec_file_is_user_supplied before the exec_file_attach in follow_exec. I'm not convinced this patch will not introduce new bugs, the whole handling of how/where executable and/or symbol files get changed seems... haphazard :) That's mainly why I'd put this patch on the back burner. I'm on the fence as to whether this should be committed, so I'll defer to you Joel. If you say commit I'll re-test and push. Cheers, Gary -- http://gbenson.net/