Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Gary Benson <gbenson@redhat.com>, gdb-patches@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>,
	       Philippe Waroquiers <philippe.waroquiers@skynet.be>,
	       Doug Evans <dje@google.com>,
	Don Breazeal <donb@codesourcery.com>
Subject: Re: [PATCH v3] Make only user-specified executable and symbol filenames sticky
Date: Fri, 03 Jul 2015 15:44:00 -0000	[thread overview]
Message-ID: <5596ADF2.7060602@redhat.com> (raw)
In-Reply-To: <1433754079-10395-1-git-send-email-gbenson@redhat.com>

Sorry for dropping the ball on this...  Comments below.

On 06/08/2015 10:01 AM, Gary Benson wrote:

> 
> 	PR gdb/17626
> 	* progspace.h (struct program_space)
> 	<pspace_exec_file_is_user_supplied>: New field.
> 	<symfile_object_file_is_user_supplied>: Likewise.
> 	(symfile_objfile_is_user_supplied): New macro.
> 	* exec.h (exec_file_is_user_supplied): Likewise.
> 	* exec.c (exec_close): Clear exec_file_is_user_supplied.
> 	(exec_file_locate_attach): Remove get_exec_file check.
> 	Do not replace user-supplied executable or symbol files.
> 	Warn if user-supplied executable or symbol files do not
> 	match discovered file.
> 	(exec_file_command): Set exec_file_is_user_supplied.
> 	* symfile.c (symbol_file_clear): Clear
> 	symfile_objfile_is_user_supplied.
> 	(symbol_file_command): Set symfile_objfile_is_user_supplied.
> 	* inferior.c (add_inferior_command): Set
> 	exec_file_is_user_supplied and symfile_objfile_is_user_supplied.
> 	* main.c (captured_main): Likewise.
> 	* infcmd.c (attach_command_post_wait): Always call
> 	exec_file_locate_attach.  Only call reopen_exec_file and
> 	reread_symbols if exec_file_is_user_supplied.
> 	* remote.c (remote_add_inferior): Remove get_exec_file check
> 	around exec_file_locate_attach.
> ---
>  gdb/ChangeLog   |   26 ++++++++++++++++++++++++++
>  gdb/exec.c      |   30 +++++++++++++++++++++++-------
>  gdb/exec.h      |    2 ++
>  gdb/infcmd.c    |   13 ++++++++-----
>  gdb/inferior.c  |    3 +++
>  gdb/main.c      |   24 ++++++++++++++++--------
>  gdb/progspace.h |   17 +++++++++++++++++
>  gdb/remote.c    |    9 ++++++---
>  gdb/symfile.c   |    3 +++
>  9 files changed, 104 insertions(+), 23 deletions(-)
> 
> diff --git a/gdb/exec.c b/gdb/exec.c
> index 8a4ab6f..11e5db0 100644
> --- a/gdb/exec.c
> +++ b/gdb/exec.c
> @@ -102,6 +102,7 @@ exec_close (void)
>  
>        xfree (exec_filename);
>        exec_filename = NULL;
> +      exec_file_is_user_supplied = 0;
>      }
>  }
>  
> @@ -142,11 +143,6 @@ exec_file_locate_attach (int pid, int from_tty)
>  {
>    char *exec_file, *full_exec_path = NULL;
>  
> -  /* Do nothing if we already have an executable filename.  */
> -  exec_file = (char *) get_exec_file (0);
> -  if (exec_file != NULL)
> -    return;
> -
>    /* Try to determine a filename from the process itself.  */
>    exec_file = target_pid_to_exec_file (pid);
>    if (exec_file == NULL)
> @@ -171,8 +167,27 @@ exec_file_locate_attach (int pid, int from_tty)
>  	full_exec_path = xstrdup (exec_file);
>      }
>  
> -  exec_file_attach (full_exec_path, from_tty);
> -  symbol_file_add_main (full_exec_path, from_tty);
> +  if (exec_file_is_user_supplied)
> +    {
> +      if (strcmp (full_exec_path, exec_filename) != 0)
> +	warning (_("Process %d has executable file %s,"
> +		   " but executable file is currently set to %s"),
> +		 pid, full_exec_path, exec_filename);
> +    }
> +  else
> +    exec_file_attach (full_exec_path, from_tty);
> +
> +  if (symfile_objfile_is_user_supplied)
> +    {
> +      const char *symbol_filename = objfile_filename (symfile_objfile);
> +
> +      if (strcmp (full_exec_path, symbol_filename) != 0)
> +	warning (_("Process %d has symbol file %s,"
> +		   " but symbol file is currently set to %s"),
> +		 pid, full_exec_path, symbol_filename);
> +    }
> +  else
> +    symbol_file_add_main (full_exec_path, from_tty);
>  }
>  


This function is called while the passed in PID is not the
current inferior.  E.g., the remote_add_inferior path.

Therefore seems to me that these symbol_file_add_main / exec_file_attach
calls can change the symbols of the wrong inferior.

(I still suspect that if we reverse the sense of the flag, then
its management ends up being more centralized, as then the
place that sets it is also the place that needs to check it,
instead of doing that in multiple places.  But, see below.)

I also notice that reread_symbols has an exec_file_attach
call which seems to me results in losing the is_user_supplied
flag if the executable's timestamp changed, at least here:

> +  /* Attempt to open the file that was executed to create this
> +     inferior.  If the user has explicitly specified executable
> +     and/or symbol files then warn the user if their choices do
> +     not match.  Otherwise, set exec_file and symfile_objfile to
> +     the new file.  */
> +  exec_file_locate_attach (ptid_get_pid (inferior_ptid), from_tty);
> +
> +  if (exec_file_is_user_supplied)
>      {
>        reopen_exec_file ();
>        reread_symbols ();


I also notice that the clone-inferior command ends up with
an exec_file_attach call in clone_program_space.  That one
should probably be setting the is_user_supplied flag too,
I'd think.  Or at least, copying it from the original.

At this point, I'm wondering about adding a parameter to
exec_file_attach to force considering (now and in future)
the right value to put in the flag in each case.

> @@ -2490,11 +2490,14 @@ attach_command_post_wait (char *args, int from_tty, int async_exec)
>    inferior = current_inferior ();
>    inferior->control.stop_soon = NO_STOP_QUIETLY;
>  
> -  /* If no exec file is yet known, try to determine it from the
> -     process itself.  */
> -  if (get_exec_file (0) == NULL)
> -    exec_file_locate_attach (ptid_get_pid (inferior_ptid), from_tty);
> -  else
> +  /* Attempt to open the file that was executed to create this
> +     inferior.  If the user has explicitly specified executable
> +     and/or symbol files then warn the user if their choices do
> +     not match.  Otherwise, set exec_file and symfile_objfile to
> +     the new file.  */
> +  exec_file_locate_attach (ptid_get_pid (inferior_ptid), from_tty);
> +
> +  if (exec_file_is_user_supplied)
>      {
>        reopen_exec_file ();
>        reread_symbols ();

It seems to me that we should be able to move these reopen/reread
calls inside exec_file_locate_attach.

Thanks,
Pedro Alves


  parent reply	other threads:[~2015-07-03 15:44 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-02  9:48 qXfer:exec-file:read and non multiprocess target Philippe Waroquiers
2015-05-05 11:02 ` Gary Benson
2015-05-05 20:45   ` Philippe Waroquiers
2015-05-06 10:31     ` Gary Benson
2015-05-06 17:10       ` [PATCH] Locate executables on remote stubs without multiprocess extensions Gary Benson
2015-05-06 17:15         ` Eli Zaretskii
2015-05-06 17:16         ` Gary Benson
2015-05-11 14:37           ` Pedro Alves
2015-05-12 11:03             ` Gary Benson
2015-05-05 15:14 ` qXfer:exec-file:read and non multiprocess target Gary Benson
2015-05-06 10:26   ` [PATCH] Make only user-specified executable filenames sticky Gary Benson
2015-05-06 12:19     ` Pedro Alves
2015-05-06 14:21       ` Pedro Alves
2015-05-06 15:20       ` Gary Benson
2015-05-11 13:57         ` Pedro Alves
2015-05-06 14:46     ` Philippe Waroquiers
2015-05-06 15:41       ` Gary Benson
2015-05-11 13:58         ` Pedro Alves
2015-05-11 20:25       ` Doug Evans
2015-05-11 17:14     ` Don Breazeal
2015-06-05  9:37       ` Gary Benson
2015-06-05 14:54         ` Don Breazeal
2015-07-03 11:14           ` Gary Benson
2015-07-06 12:53             ` Joel Brobecker
2015-07-17 21:48             ` Joel Brobecker
2015-05-11 20:23     ` Doug Evans
2015-05-12 10:36       ` Pedro Alves
2015-05-12 11:13         ` Gary Benson
2015-05-12 11:16           ` Pedro Alves
2015-05-12 13:48             ` Gary Benson
2015-05-12 14:08               ` Pedro Alves
2015-05-12 15:49         ` Doug Evans
2015-05-13  7:55           ` Gary Benson
2015-05-13  9:12             ` Pedro Alves
2015-06-03 17:23               ` Joel Brobecker
2015-06-05 11:22                 ` [PATCH v2] Make only user-specified executable and symbol " Gary Benson
2015-06-07 11:40                   ` Philippe Waroquiers
2015-06-08  9:01                     ` [PATCH v3] " Gary Benson
2015-06-08 19:42                       ` Philippe Waroquiers
2015-07-03 11:01                         ` Gary Benson
2015-07-03 15:44                       ` Pedro Alves [this message]
2015-07-06 13:01                         ` Pedro Alves
2015-06-07 12:03                   ` [PATCH v2] " Philippe Waroquiers
2015-06-07 12:13                   ` Philippe Waroquiers
2015-05-13  8:06           ` [PATCH] Make only user-specified executable " Pedro Alves
2015-05-12 16:03         ` Doug Evans
2015-05-13  8:39           ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5596ADF2.7060602@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=dje@google.com \
    --cc=donb@codesourcery.com \
    --cc=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=philippe.waroquiers@skynet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox