From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3615 invoked by alias); 11 May 2015 17:14:11 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3601 invoked by uid 89); 11 May 2015 17:14:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 May 2015 17:14:08 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YrrHI-0007Fm-SD from Don_Breazeal@mentor.com ; Mon, 11 May 2015 10:14:04 -0700 Received: from [172.30.3.27] (147.34.91.1) by SVR-ORW-FEM-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 11 May 2015 10:14:04 -0700 Message-ID: <5550E357.9040209@codesourcery.com> Date: Mon, 11 May 2015 17:14:00 -0000 From: Don Breazeal User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Gary Benson , Subject: Re: [PATCH] Make only user-specified executable filenames sticky References: <20150505151448.GA1417@blade.nx> <1430907977-30605-1-git-send-email-gbenson@redhat.com> In-Reply-To: <1430907977-30605-1-git-send-email-gbenson@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00257.txt.bz2 On 5/6/2015 3:26 AM, Gary Benson wrote: > Hi all, > > 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. > > Built and regtested on RHEL6.6 x86_64. > > Is this ok to commit? > > Cheers, > Gary > > > gdb/ChangeLog: > > * progspace.h (struct program_space) > : New field. > * exec.h (user_supplied_exec_file_p): New macro. > * exec.c (exec_close): Clear user_supplied_exec_file_p. > (exec_file_locate_attach): Remove get_exec_file check. > (exec_file_command): Set user_supplied_exec_file_p. > * inferior.c (add_inferior_command): Likewise. > * main.c (captured_main): Likewise. > * infcmd.c (attach_command_post_wait): Always try and > locate main executable if !user_supplied_exec_file_p. > * remote.c (remote_add_inferior): Likewise. > --- > gdb/ChangeLog | 14 ++++++++++++++ > gdb/exec.c | 7 ++----- > gdb/exec.h | 2 ++ > gdb/infcmd.c | 12 +++++++----- > gdb/inferior.c | 1 + > gdb/main.c | 16 +++++++++++----- > gdb/progspace.h | 7 +++++++ > gdb/remote.c | 7 ++++--- > 8 files changed, 48 insertions(+), 18 deletions(-) > > diff --git a/gdb/exec.c b/gdb/exec.c > index 8a4ab6f..278df83 100644 > --- a/gdb/exec.c > +++ b/gdb/exec.c > @@ -102,6 +102,7 @@ exec_close (void) > > xfree (exec_filename); > exec_filename = NULL; > + user_supplied_exec_file_p = 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) > @@ -376,6 +372,7 @@ exec_file_command (char *args, int from_tty) > filename = tilde_expand (*argv); > make_cleanup (xfree, filename); > exec_file_attach (filename, from_tty); > + user_supplied_exec_file_p = 1; > > do_cleanups (cleanups); > } > diff --git a/gdb/exec.h b/gdb/exec.h > index c7f3b56..3794aba 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 user_supplied_exec_file_p \ > + current_program_space->pspace_user_supplied_exec_file_p > > /* 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 7e2484b..491cbb6 100644 > --- a/gdb/infcmd.c > +++ b/gdb/infcmd.c > @@ -2467,15 +2467,17 @@ 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 > + if (user_supplied_exec_file_p) > { > reopen_exec_file (); > reread_symbols (); > } > + else > + { > + /* Attempt to open the file that was executed to create this > + inferior. */ > + exec_file_locate_attach (ptid_get_pid (inferior_ptid), from_tty); > + } > > /* Take any necessary post-attaching actions for this platform. */ > target_post_attach (ptid_get_pid (inferior_ptid)); > diff --git a/gdb/inferior.c b/gdb/inferior.c > index ba320b5..87b2133 100644 > --- a/gdb/inferior.c > +++ b/gdb/inferior.c > @@ -889,6 +889,7 @@ add_inferior_command (char *args, int from_tty) > > exec_file_attach (exec, from_tty); > symbol_file_add_main (exec, from_tty); > + user_supplied_exec_file_p = 1; > } > } > > diff --git a/gdb/main.c b/gdb/main.c > index 477fd68..9d8a196 100644 > --- a/gdb/main.c > +++ b/gdb/main.c > @@ -1051,14 +1051,20 @@ 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); > + { > + user_supplied_exec_file_p = 1; > + > + catch_command_errors_const (symbol_file_add_main, symarg, > + !batch_flag); > + } > } > else > { > - if (execarg != NULL) > - catch_command_errors_const (exec_file_attach, execarg, > - !batch_flag); > + if (execarg != NULL > + && catch_command_errors_const (exec_file_attach, execarg, > + !batch_flag)) > + user_supplied_exec_file_p = 1; > + > if (symarg != NULL) > catch_command_errors_const (symbol_file_add_main, symarg, > !batch_flag); > diff --git a/gdb/progspace.h b/gdb/progspace.h > index f960093..f8c39b6 100644 > --- 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 > + pspace_exec_filename is unset or was discovered by GDB > + somehow. */ > + int pspace_user_supplied_exec_file_p; > + > /* 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 > diff --git a/gdb/remote.c b/gdb/remote.c > index 099ddbb..b2f1bba 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -1556,9 +1556,10 @@ 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 && !fake_pid_p && get_exec_file (0) == NULL) > + /* If the user did not explicitly specify an executable file > + then attempt to open the file that was executed to create > + this inferior. */ > + if (try_open_exec && !fake_pid_p && !user_supplied_exec_file_p) > exec_file_locate_attach (pid, 1); > > return inf; > I realize that I am coming late to this discussion, sorry about that. How does this interact with follow-exec-mode? If follow-exec-mode is 'new' and the program execs, then 'run' will use the original executable file. But if follow-exec-mode is 'same' and the program execs, then 'run' will use the executable file that was active after the exec call. In the follow-exec-mode == 'same' instance, is the assumption that the exec'd executable file takes on the same 'user-supplied' attribute as the initial executable, since it is using the original inferior? If so, is there a scenario where: * the user supplies the exec file name * the program execs, so the exec file name is now different * then the user tries to do an attach (without an exec file name) to a process running the original exec file, and gets the wrong exec file name? Thanks -Don