This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Make only user-specified executable filenames sticky
- From: Gary Benson <gbenson at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- Date: Wed, 6 May 2015 16:20:00 +0100
- Subject: Re: [PATCH] Make only user-specified executable filenames sticky
- Authentication-results: sourceware.org; auth=none
- References: <20150505151448 dot GA1417 at blade dot nx> <1430907977-30605-1-git-send-email-gbenson at redhat dot com> <554A06C7 dot 6020604 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/