[v3] Make only user-specified executable and symbol filenames sticky

Message ID 1433754079-10395-1-git-send-email-gbenson@redhat.com
State New, archived
Headers

Commit Message

Gary Benson June 8, 2015, 9:01 a.m. UTC
  Philippe Waroquiers wrote:
> On Fri, 2015-06-05 at 12:22 +0100, Gary Benson wrote:
> > Built and regtested on RHEL6.6 x86_64.
> I tested with the last SVN version of the Valgrind gdbserver (that
> supports qXfer:exec-file:read+).
> 
> The patch introduces a regression:
> with the patch, GDB does not anymore automatically load the
> exec-file.
> 
> I bypassed this problem by ignoring fake_pid_p in remote.c:
> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -1624,9 +1624,13 @@ remote_add_inferior (int fake_pid_p, int pid, int
> attached,
>    inf->attach_flag = attached;
>    inf->fake_pid_p = fake_pid_p;
>  
> -  /* If no main executable is currently open then attempt to
> -     open the file that was executed to create this inferior.  */
> -  if (try_open_exec && get_exec_file (0) == NULL)
> +  /* 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.  */
> +  printf("fake_pid_p %d\n", fake_pid_p);
> +  if (try_open_exec)// && !fake_pid_p)
>      exec_file_locate_attach (pid, 1);
> 
> Effectively, the printf shows that with Valgrind gdbsrv,
> fake_pid_p value is 1.
> 
> When ignoring fake_pid_p, GDB can properly attach
> to different Valgrind gdbsrv, and changes of executable
> as expected.

Ah, it seems I mailed a bad patch, my apologies!  I was working on
two fixes that touched the same line, and it looks like I rebased
them in the wrong order.

This updated patch has been created against the latest gdb/master
(80fb91378c91a8239817a5ab2b1c3e346109db25).  Could you please try
your tests again?

Thanks,
Gary


---
On attach, GDB will only attempt to determine the main executable's
filename if one is not already 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 is PR gdb/17626.

In GDB some filenames are supplied by the user (e.g. using the "file"
or "symbol-file" commands) and some are determined by GDB (e.g. while
processing an "attach" command).  This commit updates GDB to track
which 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.

gdb/ChangeLog:

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

Comments

Philippe Waroquiers June 8, 2015, 7:41 p.m. UTC | #1
On Mon, 2015-06-08 at 10:01 +0100, Gary Benson wrote:

> This updated patch has been created against the latest gdb/master
> (80fb91378c91a8239817a5ab2b1c3e346109db25).  Could you please try
> your tests again?
First test with 'native' attach/detach/attach/detach/attach is
working ok.
However, the behaviour of the 3rd attach differs: a question
is asked, that is answered automatically as yes (for EOF).
So that is strange.
        GNU gdb (GDB) 7.9.50.20150608-cvs
        ...
        Type "apropos word" to search for commands related to "word".
        (gdb) atta 13286
        Attaching to process 13286
        Reading symbols from /bin/sleep...(no debugging symbols found)...done.
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f3c5bb06f20 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) detach
        Detaching from program: /bin/sleep, process 13286
        (gdb) atta 13320
        Attaching to program: /bin/sleep, process 13320
        Reading symbols from /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers...done.
        Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
        [New LWP 13323]
        [New LWP 13322]
        [New LWP 13321]
        [Thread debugging using libthread_db enabled]
        Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f5f538e1da3 in select () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13320
        (gdb) atta 13286
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13286
        Load new symbol table from "/bin/sleep"? (y or n) EOF [assumed Y]
        Reading symbols from /bin/sleep...(no debugging symbols found)...done.
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f3c5bb06f20 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) 

2nd test is with Valgrind gdbsrv. Also working ok. However, here
we have a question (no EOF answer) asking to change or not the symbol file.
        GNU gdb (GDB) 7.9.50.20150608-cvs
        ...
        Type "apropos word" to search for commands related to "word".
        (gdb) tar rem | lvgdb
        Remote debugging using | lvgdb
        relaying data between gdb and process 13394
        warning: remote target does not support file transfer, attempting to access files from local filesystem.
        Reading symbols from /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00000000040012d0 in ?? () from /lib64/ld-linux-x86-64.so.2
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, Remote target
        Ending remote debugging.
        (gdb) tar rem | lvgdb --pid=13413
        Remote debugging using | lvgdb --pid=13413
        relaying data between gdb and process 13413
        Load new symbol table from "/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak"? (y or n) y
        Reading symbols from /home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00000000040012d0 in ?? () from /lib64/ld-linux-x86-64.so.2
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak, Remote target
        Ending remote debugging.
        (gdb) tar rem | lvgdb --pid=13394
        Remote debugging using | lvgdb --pid=13394
        relaying data between gdb and process 13394
        Load new symbol table from "/home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers"? (y or n) y
        Reading symbols from /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers...done.
        Reading symbols from /home/philippe/valgrind/trunk_untouched/./.in_place/vgpreload_core-amd64-linux.so...done.
        Reading symbols from /home/philippe/valgrind/trunk_untouched/./.in_place/vgpreload_memcheck-amd64-linux.so...done.
        Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x0000000005145da3 in select () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) tar rem | lvgdb --pid=13427
        A program is being debugged already.  Kill it? (y or n) n
        Program not killed.
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, Remote target
        Ending remote debugging.
        (gdb) tar rem | lvgdb --pid=13427
        Remote debugging using | lvgdb --pid=13427
        relaying data between gdb and process 13427
        Load new symbol table from "/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak"? (y or n) y
        Reading symbols from /home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00000000040012d0 in ?? () from /lib64/ld-linux-x86-64.so.2
        (gdb) 

3rd test with GDB gdbserver: there is still the problem of invalid
target.
        GNU gdb (GDB) 7.9.50.20150608-cvs
        ...
        Type "apropos word" to search for commands related to "word".
        (gdb) tar rem :1234
        Remote debugging using :1234
        Reading symbols from target:/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak...done.
        Reading symbols from target:/lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007ffff7ddb2d0 in ?? () from target:/lib64/ld-linux-x86-64.so.2
        (gdb) detach
        Detaching from program: target:/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak, process 13447
        Ending remote debugging.
        (gdb) tar rem :1235
        `target:/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak' has disappeared; keeping its symbols.
        Remote debugging using :1235
        Load new symbol table from "target:/home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers"? (y or n) y
        Reading symbols from target:/home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers...Can't read symbols from target:/home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers: Invalid argument
        (gdb) 

Test 4 is the same as test 1, but with gdb started with a filename as argument.
GDB gives a warning that the exec+sym file does not match the target one.
        gdb ./gdbserver_tests/sleepers 
        ...
        Type "apropos word" to search for commands related to "word"...
        Reading symbols from ./gdbserver_tests/sleepers...done.
        (gdb) atta 13474
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13474
        Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
        [New LWP 13477]
        [New LWP 13476]
        [New LWP 13475]
        [Thread debugging using libthread_db enabled]
        Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007fec5b318da3 in select () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13474
        (gdb) atta 13484
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13484
        warning: Process 13484 has executable file /bin/sleep, but executable file is currently set to /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers
        warning: Process 13484 has symbol file /bin/sleep, but symbol file is currently set to /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f1d71fdef20 in ?? ()
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13484
        (gdb) atta 13474
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13474
        Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
        [New LWP 13477]
        [New LWP 13476]
        [New LWP 13475]
        [Thread debugging using libthread_db enabled]
        Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007fec5b318da3 in select () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13474
        (gdb) atta 13484
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13484
        warning: Process 13484 has executable file /bin/sleep, but executable file is currently set to /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers
        warning: Process 13484 has symbol file /bin/sleep, but symbol file is currently set to /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f1d71fdef20 in ?? ()
        (gdb) file /bin/sleep
        A program is being debugged already.
        Are you sure you want to change the file? (y or n) y
        Load new symbol table from "/bin/sleep"? (y or n) y
        Reading symbols from /bin/sleep...(no debugging symbols found)...done.
        (gdb) detach
        Detaching from program: /bin/sleep, process 13484
        (gdb) atta 13474     
        Attaching to program: /bin/sleep, process 13474
        warning: Process 13474 has executable file /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, but executable file is currently set to /bin/sleep
        warning: Process 13474 has symbol file /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, but symbol file is currently set to /bin/sleep
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007fec5b318da3 in ?? ()
        (gdb) 
        


So, in summary, this patch version is better but there are still some
strange behaviours.

In terms of behaviour, it is somewhat surprising to sometimes have a question,
sometimes not. IMO, it would be better to always ask a question when the currently loaded
file does not match the target file (native attach or remote target), even when
the file was supplied by the user.

Philippe
  
Gary Benson July 3, 2015, 11:01 a.m. UTC | #2
Philippe Waroquiers wrote:
> On Mon, 2015-06-08 at 10:01 +0100, Gary Benson wrote:
> > This updated patch has been created against the latest gdb/master
> > (80fb91378c91a8239817a5ab2b1c3e346109db25).  Could you please try
> > your tests again?
> 
> First test with 'native' attach/detach/attach/detach/attach is
> working ok.
> However, the behaviour of the 3rd attach differs: a question
> is asked, that is answered automatically as yes (for EOF).
> So that is strange.
>         GNU gdb (GDB) 7.9.50.20150608-cvs
>         ...
>         Type "apropos word" to search for commands related to "word".
>         (gdb) atta 13286
>         Attaching to process 13286
>         Reading symbols from /bin/sleep...(no debugging symbols found)...done.
>         Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
>         Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
>         0x00007f3c5bb06f20 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
>         (gdb) detach
>         Detaching from program: /bin/sleep, process 13286
>         (gdb) atta 13320
>         Attaching to program: /bin/sleep, process 13320
>         Reading symbols from /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers...done.
>         Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
>         [New LWP 13323]
>         [New LWP 13322]
>         [New LWP 13321]
>         [Thread debugging using libthread_db enabled]
>         Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>         Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
>         Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
>         0x00007f5f538e1da3 in select () from /lib/x86_64-linux-gnu/libc.so.6
>         (gdb) detach
>         Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13320
>         (gdb) atta 13286
>         Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13286
>         Load new symbol table from "/bin/sleep"? (y or n) EOF [assumed Y]
>         Reading symbols from /bin/sleep...(no debugging symbols found)...done.
>         Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
>         Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
>         0x00007f3c5bb06f20 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
>         (gdb) 

I don't see the question:

  GNU gdb (GDB) 7.9.50.20150703-cvs
  Copyright (C) 2015 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-unknown-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  <http://www.gnu.org/software/gdb/bugs/>.
  Find the GDB manual and other documentation resources online at:
  <http://www.gnu.org/software/gdb/documentation/>.
  For help, type "help".
  Type "apropos word" to search for commands related to "word".
  (gdb) atta 15450
  Attaching to process 15450
  Reading symbols from /bin/sleep...(no debugging symbols found)...done.
  Reading symbols from /lib64/libc.so.6...warning: the debug information found in "/usr/lib/debug//lib64/libc-2.12.so.debug" does not match "/lib64/libc.so.6" (CRC mismatch).
  (no debugging symbols found)...done.
  Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.12.so.debug...warning: Skipping deprecated .gdb_index section in /usr/lib/debug/lib64/ld-2.12.so.debug.
  Do "set use-deprecated-index-sections on" before the file is read
  to use the section anyway.
  done.
  done.
  0x00000039b54aca20 in __nanosleep_nocancel () from /lib64/libc.so.6
  (gdb) detach
  Detaching from program: /bin/sleep, process 15450
  (gdb) atta 15465
  Attaching to program: /bin/sleep, process 15465
  Reading symbols from /bin/sleep...(no debugging symbols found)...done.
  Reading symbols from /lib64/libc.so.6...warning: the debug information found in "/usr/lib/debug//lib64/libc-2.12.so.debug" does not match "/lib64/libc.so.6" (CRC mismatch).
  (no debugging symbols found)...done.
  Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.12.so.debug...done.
  done.
  0x00000039b54aca20 in __nanosleep_nocancel () from /lib64/libc.so.6
  (gdb) detach
  Detaching from program: /bin/sleep, process 15465
  (gdb) atta 15450
  Attaching to program: /bin/sleep, process 15450
  Reading symbols from /bin/sleep...(no debugging symbols found)...done.
  Reading symbols from /lib64/libc.so.6...warning: the debug information found in "/usr/lib/debug//lib64/libc-2.12.so.debug" does not match "/lib64/libc.so.6" (CRC mismatch).
  (no debugging symbols found)...done.
  Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.12.so.debug...done.
  done.
  0x00000039b54aca20 in __nanosleep_nocancel () from /lib64/libc.so.6
  (gdb) 

I did notice that if you do the second or third attach without a
detach GDB asks "A program is being debugged already.  Kill it?"
That's not what I'd expect (I'd expect GDB to offer to detach).
But that's a separate issue...

Joel, should I commit this patch?  FAOD it's
https://sourceware.org/ml/gdb-patches/2015-06/msg00110.html

Thanks,
Gary
  
Pedro Alves July 3, 2015, 3:44 p.m. UTC | #3
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
  

Patch

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);
 }
 
 /* Set FILENAME as the new exec file.
@@ -376,6 +391,7 @@  exec_file_command (char *args, int from_tty)
       filename = tilde_expand (*argv);
       make_cleanup (xfree, filename);
       exec_file_attach (filename, from_tty);
+      exec_file_is_user_supplied = 1;
 
       do_cleanups (cleanups);
     }
diff --git a/gdb/exec.h b/gdb/exec.h
index c7f3b56..d984e97 100644
--- 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 exec_file_is_user_supplied \
+  current_program_space->pspace_exec_file_is_user_supplied
 
 /* Builds a section table, given args BFD, SECTABLE_PTR, SECEND_PTR.
    Returns 0 if OK, 1 on error.  */
diff --git a/gdb/infcmd.c b/gdb/infcmd.c
index 03282a7..e43b299 100644
--- a/gdb/infcmd.c
+++ b/gdb/infcmd.c
@@ -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 ();
diff --git a/gdb/inferior.c b/gdb/inferior.c
index d0783d3..ea00121 100644
--- a/gdb/inferior.c
+++ b/gdb/inferior.c
@@ -888,7 +888,10 @@  add_inferior_command (char *args, int from_tty)
 	  switch_to_thread (null_ptid);
 
 	  exec_file_attach (exec, from_tty);
+	  exec_file_is_user_supplied = 1;
+
 	  symbol_file_add_main (exec, from_tty);
+	  symfile_objfile_is_user_supplied = 1;
 	}
     }
 
diff --git a/gdb/main.c b/gdb/main.c
index aecd60a..ae2803c 100644
--- a/gdb/main.c
+++ b/gdb/main.c
@@ -1050,17 +1050,25 @@  captured_main (void *data)
          catch_command_errors returns non-zero on success!  */
       if (catch_command_errors_const (exec_file_attach, execarg,
 				      !batch_flag))
-	catch_command_errors_const (symbol_file_add_main, symarg,
-				    !batch_flag);
+	{
+	  exec_file_is_user_supplied = 1;
+
+	  if (catch_command_errors_const (symbol_file_add_main, symarg,
+					  !batch_flag))
+	    symfile_objfile_is_user_supplied = 1;
+	}
     }
   else
     {
-      if (execarg != NULL)
-	catch_command_errors_const (exec_file_attach, execarg,
-				    !batch_flag);
-      if (symarg != NULL)
-	catch_command_errors_const (symbol_file_add_main, symarg,
-				    !batch_flag);
+      if (execarg != NULL
+	  && catch_command_errors_const (exec_file_attach, execarg,
+					 !batch_flag))
+	exec_file_is_user_supplied = 1;
+
+      if (symarg != NULL
+	  && catch_command_errors_const (symbol_file_add_main, symarg,
+					 !batch_flag))
+	symfile_objfile_is_user_supplied = 1;
     }
 
   if (corearg && pidarg)
diff --git a/gdb/progspace.h b/gdb/progspace.h
index f960093..561e093 100644
--- a/gdb/progspace.h
+++ b/gdb/progspace.h
@@ -154,6 +154,12 @@  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 the "file"
+       or "add-inferior -exec" commands.  Zero if
+       pspace_exec_filename is unset or was discovered by GDB.  */
+    int pspace_exec_file_is_user_supplied;
+
     /* The address space attached to this program space.  More than one
        program space may be bound to the same address space.  In the
        traditional unix-like debugging scenario, this will usually
@@ -183,6 +189,12 @@  struct program_space
        (e.g. the argument to the "symbol-file" or "file" command).  */
     struct objfile *symfile_object_file;
 
+    /* Nonzero if symfile_object_file was supplied by the user,
+       either at startup (on the command-line) or via the "file",
+       "symbol-file" or "add-inferior -exec" commands.  Zero if
+       symfile_object_file is unset or was discovered by GDB.  */
+    int symfile_object_file_is_user_supplied;
+
     /* All known objfiles are kept in a linked list.  This points to
        the head of this list.  */
     struct objfile *objfiles;
@@ -215,6 +227,11 @@  struct program_space
 
 #define symfile_objfile current_program_space->symfile_object_file
 
+/* See program_space->symfile_object_file_is_user_supplied.  */
+
+#define symfile_objfile_is_user_supplied \
+  current_program_space->symfile_object_file_is_user_supplied
+
 /* All known objfiles are kept in a linked list.  This points to the
    root of this list.  */
 #define object_files current_program_space->objfiles
diff --git a/gdb/remote.c b/gdb/remote.c
index 53918ca..955ea86 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -1624,9 +1624,12 @@  remote_add_inferior (int fake_pid_p, int pid, int attached,
   inf->attach_flag = attached;
   inf->fake_pid_p = fake_pid_p;
 
-  /* If no main executable is currently open then attempt to
-     open the file that was executed to create this inferior.  */
-  if (try_open_exec && get_exec_file (0) == NULL)
+  /* 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.  */
+  if (try_open_exec)
     exec_file_locate_attach (pid, 1);
 
   return inf;
diff --git a/gdb/symfile.c b/gdb/symfile.c
index 0c35ffa..d44cb7d 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -1347,6 +1347,8 @@  symbol_file_clear (int from_tty)
   gdb_assert (symfile_objfile == NULL);
   if (from_tty)
     printf_unfiltered (_("No symbol file now.\n"));
+
+  symfile_objfile_is_user_supplied = 0;
 }
 
 static int
@@ -1664,6 +1666,7 @@  symbol_file_command (char *args, int from_tty)
 	  else
 	    {
 	      symbol_file_add_main_1 (*argv, from_tty, flags);
+	      symfile_objfile_is_user_supplied = 1;
 	      name = *argv;
 	    }