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

Gary Benson
2015-05-06T15:20:08Z

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.

> 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. Should they both be protected individually do you
think? I'm leaning that way.

> This fixes PR 17626 (so please add that to the ChangeLog), which is
> marked as duplicate of PR 16266 currently, but in a different way
> than 16266 suggests.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=16266
> https://sourceware.org/bugzilla/show_bug.cgi?id=17626

Ok.

> I think this needs a NEWS entry, and probably a tweak to the
> manual somewhere.

Ok.

> > --- 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)?

> > --- a/gdb/progspace.h
> > +++ b/gdb/progspace.h
> > @@ -154,6 +154,13 @@ struct program_space
> > It needs to be freed by xfree. It is not NULL iff EBFD is not NULL. */
> > char *pspace_exec_filename;
> >
> > + /* Nonzero if pspace_exec_filename was supplied by the user,
> > + either at startup (on the command-line) or via a "file"
> > + an "add-inferior -exec" command. Zero if
>
> Sounds like an "or" is missing between the commands.

Got it.

Thanks,
Gary

--