Re: [PATCH] Make only user-specified executable filenames sticky

[Pedro Alves <palves@redhat.com>]

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