From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119382 invoked by alias); 11 May 2015 13:57: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 119369 invoked by uid 89); 11 May 2015 13:57:28 -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; Mon, 11 May 2015 13:57:27 +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 19A8EBBDC; Mon, 11 May 2015 13:57:26 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4BDvNKf028866; Mon, 11 May 2015 09:57:24 -0400 Message-ID: <5550B543.1000203@redhat.com> Date: Mon, 11 May 2015 13:57: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: Gary Benson CC: gdb-patches@sourceware.org, 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> <554A06C7.6020604@redhat.com> <20150506152000.GB29283@blade.nx> In-Reply-To: <20150506152000.GB29283@blade.nx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00252.txt.bz2 On 05/06/2015 04:20 PM, Gary Benson wrote: > Pedro Alves wrote: >> On 05/06/2015 11: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 have a feeling this would be simpler if the flag's sense was >> reversed? That is, mark the exec as auto-discovered instead of >> marking it user-loaded. > > I'm easy either way. I spent about four hours trying to name the > flag (and thinking about making it an enum) so right now I'm about > ready to be told what to do :) > > I think having the sense the other way around would make the checks > more complex, you'd have to check for exec_file being empty as well > as being auto-discovered. If the user set it it isn't empty. It's not that complex, and, both the checks and the sets of the flags would only appear in places that relate to auto-discovery, instead of setting the flag in the several user-specified code paths (which seem to be more than the auto-discover paths), and then checking them in the auto-discover paths; seems more centralized to keep most things in the auto-discover paths. > >> How does this interact with "symbol-file FILE" ? > > I'm not sure... badly? :) > :-) > exec_file_locate_attach (the bit that does the auto-discovery) does > both exec_file_attach and symbol_file_add_main. file_command also > does both, albeit indirectly, and add_inferior_command does both > too. But, on startup you can specify separate symbol file, and of > course you can use the symbol-file command. > > I don't really know in what circumstances you would use a separate > symbol file. Yeah, I don't think it's a very common thing to do. At least not on systems where the same file format holds both the executable and the debug info. Not all systems are like that: I'm thinking of Symbian, with PE dll files for exec file, and ELF .sym files for symbols (https://sourceware.org/ml/gdb-patches/2010-03/msg00237.html), or even Windows' pdb files (which we don't support, but alas). Maybe there are more systems like that. > Should they both be protected individually do you > think? I'm leaning that way. Yeah, that might be the simplest/best option, as opposed to trying to come up with rules/policy related to how symbol-file and exec-file influence each other. > >>> --- a/gdb/exec.h >>> +++ b/gdb/exec.h >>> @@ -32,6 +32,8 @@ struct objfile; >>> #define exec_bfd current_program_space->ebfd >>> #define exec_bfd_mtime current_program_space->ebfd_mtime >>> #define exec_filename current_program_space->pspace_exec_filename >>> +#define user_supplied_exec_file_p \ >>> + current_program_space->pspace_user_supplied_exec_file_p >> >> Nit, but I'd suggest 'exec_file_is_user_supplied', which would >> fit the pattern of vars related to the exec being prefixed exec_. > > Ok. Or exec_file_is_sticky (and symfile_is_sticky)? Sounds fine. Thanks, Pedro Alves