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

Pedro Alves
2015-05-11T13:57:29Z

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