From patchwork Mon Mar 18 22:58:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Philippe Waroquiers X-Patchwork-Id: 31905 Received: (qmail 29961 invoked by alias); 18 Mar 2019 22:58:36 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 29953 invoked by uid 89); 18 Mar 2019 22:58:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.1 spammy=understandable, det, actions, topgdb X-HELO: mailsec111.isp.belgacom.be Received: from mailsec111.isp.belgacom.be (HELO mailsec111.isp.belgacom.be) (195.238.20.107) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Mar 2019 22:58:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1552949911; x=1584485911; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=E1GzUHElNJUbpyie4yJ3j2EWGmWQvwMHmXJUdzIFRiA=; b=lahLQadkCtc3qzEdW+Lfw7pAqS32HbLGdCUCj65kXuqyyl9kTbi1EEY5 pXz6qIOPFlFov8xPbp5oIcYk4uX0qw==; Received: from 147.122-130-109.adsl-dyn.isp.belgacom.be (HELO md.home) ([109.130.122.147]) by relay.skynet.be with ESMTP/TLS/DHE-RSA-AES128-GCM-SHA256; 18 Mar 2019 23:58:28 +0100 From: Philippe Waroquiers To: gdb-patches@sourceware.org Cc: Philippe Waroquiers Subject: [RFC] Have an option to tell GDB to detect and possibly handle mismatched exec-files. Date: Mon, 18 Mar 2019 23:58:22 +0100 Message-Id: <20190318225822.4820-1-philippe.waroquiers@skynet.be> MIME-Version: 1.0 X-IsSubscribed: yes A recurrent problem with GDB is that GDB uses the wrong exec-file when using the attach/detach commands sucessfully. Also, in case the user specifies a file on the command line but attaches to the wrong PID, this error is not made visible and gives a not user understandable behaviour. For example: $ gdb ... (gdb) atta 2682 Attaching to process 2682 [New LWP 2683] [New LWP 2684] [New LWP 2685] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) det Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682 [Inferior 1 (process 2682) detached] (gdb) atta 31069 Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069 Reading symbols from /lib64/ld-linux-x86-64.so.2... Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug... 0x00007f43c23478a0 in ?? () (gdb) bt #0 0x00007f43c23478a0 in ?? () #1 0x0000558909e3ad91 in ?? () #2 0x0000202962646700 in ?? () #3 0x00007ffc69c74e70 in ?? () #4 0x000055890c1d2350 in ?? () #5 0x0000000000000000 in ?? () (gdb) The second attach has kept the executable of the first attach. (in this case, 31069 is the PID of a GDB, that has nothing to do with the first determined 'sleepers' executable). Similarly, if specifying an executable, but attaching to a wrong pid, we get: gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers ... Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers... (gdb) atta 31069 Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069 Reading symbols from /lib64/ld-linux-x86-64.so.2... Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug... 0x00007f43c23478a0 in ?? () (gdb) bt #0 0x00007f43c23478a0 in ?? () #1 0x0000558909e3ad91 in ?? () #2 0x0000202962646700 in ?? () #3 0x00007ffc69c74e70 in ?? () #4 0x000055890c1d2350 in ?? () #5 0x0000000000000000 in ?? () (gdb) And it is unclear to the user what has happened/what is going wrong. This patch series implements a new option: (gdb) apropos exec-file-mismatch set exec-file-mismatch -- Set exec-file-mismatch handling show exec-file-mismatch -- Show exec-file-mismatch handling (gdb) help set exec-file-mismatch Set exec-file-mismatch handling. (reload/warn/off) (gdb) "reload" means: in case of mismatch between the current exec-file and the automatically determined exec-file of the PID we are attaching to, give a warning to the user and reload the automatically determined exec-file. This reload might be subject to a question to the user. "warn" means: in case of mismatch, just give a warning to the user. "off" means: do not check for mismatch. This fixes PR gdb/17626. There was a previous trial to fix this PR. See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html This trial was however only fixing the problem for the automatically determined executable files when doing attach. It was differentiating the 'user specified executable files' ("sticky") from the executable files automatically found by GDB. But such user specified sticky executables are in most cases due to a wrong manipulation by the user, giving unexpected results such as backtrace showing no function like in the above example. This patch ensures that whenever a process executable can be determined, that the user is warned if there is a mismatch. The same tests as above then give: (gdb) atta 2682 Attaching to process 2682 [New LWP 2683] [New LWP 2684] [New LWP 2685] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) det Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682 [Inferior 1 (process 2682) detached] (gdb) atta 31069 Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069 warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb exec-file-mismatch handling is currently "reload" Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb... Setting up the environment for debugging gdb. ... Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug... 0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (top-gdb) bt During symbol reading: incomplete CFI data; unspecified registers (e.g., rax) at 0x7f43c23478ad During symbol reading: unsupported tag: 'DW_TAG_unspecified_type' During symbol reading: cannot get low and high bounds for subprogram DIE at 0x12282a7 During symbol reading: Child DIE 0x12288ba and its abstract origin 0x1228b26 have different parents During symbol reading: DW_AT_call_target target DIE has invalid low pc, for referencing DIE 0x1229540 [in module /bd/home/philippe/gdb/git/build_fixes/gdb/gdb] #0 0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x0000558909e3ad91 in poll (__timeout=-1, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46 #2 gdb_wait_for_event (block=block@entry=1) at ../../fixes/gdb/event-loop.c:772 #3 0x0000558909e3aef4 in gdb_do_one_event () at ../../fixes/gdb/event-loop.c:347 #4 0x0000558909e3b085 in gdb_do_one_event () at ../../fixes/gdb/common/common-exceptions.h:219 #5 start_event_loop () at ../../fixes/gdb/event-loop.c:371 During symbol reading: Member function "~_Sp_counted_base" (offset 0x1c69bf7) is virtual but the vtable offset is not specified During symbol reading: Multiple children of DIE 0x1c8f5a0 refer to DIE 0x1c8f0ee as their abstract origin #6 0x0000558909ed3b78 in captured_command_loop () at ../../fixes/gdb/main.c:331 #7 0x0000558909ed4b6d in captured_main (data=) at ../../fixes/gdb/main.c:1174 #8 gdb_main (args=) at ../../fixes/gdb/main.c:1190 #9 0x0000558909c1e9a8 in main (argc=, argv=) at ../../fixes/gdb/gdb.c:32 (top-gdb) gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepersReading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers... (gdb) atta 31069 Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069 warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb exec-file-mismatch handling is currently "reload" Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb... Setting up the environment for debugging gdb. .... In other words, it now works as intuitively expected by the user. If ever the user gave the correct executable on the command line, then attached to the wrong pid, then confirmed loading the wrong executable, the user can simply fix this by detaching, and attaching to the correct pid, GDB will then tell again to the user that the exec-file might better be reloaded. The default value of "reload" is chosen instead of e.g. "warn" as in most cases, switching of executable will be the correct action, and in any case, the user can decide to not load the executable. Tested on debian/amd64, no regression. Still missing: ChangeLog NEWS user manual --- gdb/exec.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++ gdb/gdbcore.h | 5 +++ gdb/infcmd.c | 3 ++ gdb/remote.c | 3 ++ 4 files changed, 115 insertions(+) diff --git a/gdb/exec.c b/gdb/exec.c index 77bd140a8e..054753d793 100644 --- a/gdb/exec.c +++ b/gdb/exec.c @@ -82,6 +82,49 @@ struct exec_target final : public target_ops static exec_target exec_ops; +/* How to handle a mismatch between the current exec file and the exec + file determined from target. */ + +static const char *const exec_file_mismatch_names[] + = {"reload", "warn", "off", NULL }; +enum exec_file_mismatch_mode + { + exec_file_mismatch_reload, exec_file_mismatch_warn, exec_file_mismatch_off + }; +static const char *exec_file_mismatch = exec_file_mismatch_names[0]; +enum exec_file_mismatch_mode exec_file_mismatch_mode = exec_file_mismatch_reload; + +/* Show command. */ +static void +show_exec_file_mismatch_command (struct ui_file *file, int from_tty, + struct cmd_list_element *c, const char *value) +{ + fprintf_filtered (gdb_stdout, + _("exec-file-mismatch handling is currently \"%s\".\n"), + exec_file_mismatch_names[exec_file_mismatch_mode]); +} + +/* Set command. Change the setting for range checking. */ +static void +set_exec_file_mismatch_command (const char *ignore, + int from_tty, struct cmd_list_element *c) +{ + for (enum exec_file_mismatch_mode mode = exec_file_mismatch_reload; + ; + mode = static_cast(1 + (int) mode)) + { + if (strcmp (exec_file_mismatch, exec_file_mismatch_names[mode]) == 0) + { + exec_file_mismatch_mode = mode; + return; + } + if (mode == exec_file_mismatch_off) + internal_error (__FILE__, __LINE__, + _("Unrecognized exec-file-mismatch setting: \"%s\""), + exec_file_mismatch); + } +} + /* Whether to open exec and core files read-only or read-write. */ int write_files = 0; @@ -201,6 +244,56 @@ try_open_exec_file (const char *exec_file_host, struct inferior *inf, /* See gdbcore.h. */ +void +validate_exec_file (int from_tty) +{ + if (exec_file_mismatch_mode == exec_file_mismatch_off) + return; /* User asked to do nothing. */ + + char *current_exec_file = get_exec_file (0); + struct inferior *inf = current_inferior (); + /* Try to determine a filename from the process itself. */ + char *pid_exec_file = target_pid_to_exec_file (inf->pid); + + if (current_exec_file == NULL || pid_exec_file == NULL) + return; /* We cannot validate the exec file. */ + + std::string exec_file_target (pid_exec_file); + + /* In case the exec file is not local, exec_file_target has to point at + the target file system. */ + if (is_target_filename (current_exec_file) && !target_filesystem_is_local ()) + exec_file_target = TARGET_SYSROOT_PREFIX + exec_file_target; + + if (strcmp (exec_file_target.c_str (), current_exec_file) != 0) + { + warning (_("Mismatch between current exec-file %s\n" + "and automatically determined exec-file %s\n" + "exec-file-mismatch handling is currently \"%s\""), + current_exec_file, exec_file_target.c_str (), + exec_file_mismatch_names[exec_file_mismatch_mode]); + if (exec_file_mismatch_mode == exec_file_mismatch_reload) + { + symfile_add_flags add_flags = SYMFILE_MAINLINE; + if (from_tty) + add_flags |= SYMFILE_VERBOSE; + TRY + { + symbol_file_add_main (exec_file_target.c_str (), add_flags); + exec_file_attach (exec_file_target.c_str (), from_tty); + } + CATCH (err, RETURN_MASK_ERROR) + { + warning (_("reloading %s %s"), exec_file_target.c_str (), + err.message != NULL ? err.message : "error"); + } + END_CATCH + } + } +} + +/* See gdbcore.h. */ + void exec_file_locate_attach (int pid, int defer_bp_reset, int from_tty) { @@ -1084,5 +1177,16 @@ Show writing into executable and core files."), NULL, show_write_files, &setlist, &showlist); + add_setshow_enum_cmd ("exec-file-mismatch", class_support, + exec_file_mismatch_names, + &exec_file_mismatch, + _("\ +Set exec-file-mismatch handling. (reload/warn/off)"), + _("\ +Show exec-file-mismatch handling. (reload/warn/off"), + NULL, set_exec_file_mismatch_command, + show_exec_file_mismatch_command, + &setlist, &showlist); + add_target (exec_target_info, exec_target_open, filename_completer); } diff --git a/gdb/gdbcore.h b/gdb/gdbcore.h index 6f9b4d88ec..611a389e22 100644 --- a/gdb/gdbcore.h +++ b/gdb/gdbcore.h @@ -157,6 +157,11 @@ extern void exec_file_locate_attach (int pid, int defer_bp_reset, int from_tty); extern void validate_files (void); +/* Produce a warning if the current exec file does not match the exec + file determined from the target. In case of mismatch, ask the user + if the exec file determined from target must be loaded. */ +extern void validate_exec_file (int from_tty); + /* The current default bfd target. */ extern char *gnutarget; diff --git a/gdb/infcmd.c b/gdb/infcmd.c index c5977c48a9..5812827ae5 100644 --- a/gdb/infcmd.c +++ b/gdb/infcmd.c @@ -2560,6 +2560,9 @@ setup_inferior (int from_tty) reread_symbols (); } + /* Check for exec file mismatch, and let the user solve it. */ + validate_exec_file (from_tty); + /* Take any necessary post-attaching actions for this platform. */ target_post_attach (inferior_ptid.pid ()); diff --git a/gdb/remote.c b/gdb/remote.c index 657a4a25ca..c0c80ee140 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -2392,6 +2392,9 @@ remote_target::remote_add_inferior (int fake_pid_p, int pid, int attached, if (try_open_exec && get_exec_file (0) == NULL) exec_file_locate_attach (pid, 0, 1); + /* Check for exec file mismatch, and let the user solve it. */ + validate_exec_file (1); + return inf; }