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

[Gary Benson <gbenson at redhat dot com>]

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

-- 
http://gbenson.net/