http://sourceware.org/ml/gdb-patches/2016-03/msg00013.html Subject: [PATCH 1/2] Fix PR gdb/19676: Disable displaced stepping if /proc not mounted On GNU/Linux archs that support displaced stepping, if /proc is not mounted, GDB gets stuck not able to step past breakpoints: (gdb) c Continuing. dl_main (phdr=, phnum=, user_entry=, auxv=) at rtld.c:2163 2163 LIBC_PROBE (init_complete, 2, LM_ID_BASE, r); Cannot find AT_ENTRY auxiliary vector entry. (gdb) c Continuing. dl_main (phdr=, phnum=, user_entry=, auxv=) at rtld.c:2163 2163 LIBC_PROBE (init_complete, 2, LM_ID_BASE, r); Cannot find AT_ENTRY auxiliary vector entry. (gdb) That's because GDB can't figure out where the scratch pad is. This is a regression introduced by the earlier changes to make the Linux native target always work in non-stop mode. This commit makes GDB detect the case and fallback to stepping over breakpoints in-line. gdb/ChangeLog: 2016-03-01 Pedro Alves PR gdb/19676 * infrun.c (displaced_step_prepare): Also disable displaced stepping on NOT_SUPPORTED_ERROR. * linux-tdep.c (linux_displaced_step_location): If reading auxv fails, throw NOT_SUPPORTED_ERROR instead of generic error. --- gdb/infrun.c | 3 ++- gdb/linux-tdep.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/gdb/infrun.c b/gdb/infrun.c index 3e8c9e0..696105d 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1894,7 +1894,8 @@ displaced_step_prepare (ptid_t ptid) { struct displaced_step_inferior_state *displaced_state; - if (ex.error != MEMORY_ERROR) + if (ex.error != MEMORY_ERROR + && ex.error != NOT_SUPPORTED_ERROR) throw_exception (ex); if (debug_infrun) diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c index 555c302..f197aa7 100644 --- a/gdb/linux-tdep.c +++ b/gdb/linux-tdep.c @@ -2426,7 +2426,8 @@ linux_displaced_step_location (struct gdbarch *gdbarch) location. The auxiliary vector gets us the PowerPC-side entry point address instead. */ if (target_auxv_search (¤t_target, AT_ENTRY, &addr) <= 0) - error (_("Cannot find AT_ENTRY auxiliary vector entry.")); + throw_error (NOT_SUPPORTED_ERROR, + _("Cannot find AT_ENTRY auxiliary vector entry.")); /* Make certain that the address points at real code, and not a function descriptor. */ -- 2.5.0 http://sourceware.org/ml/gdb-patches/2016-03/msg00014.html Subject: [PATCH 2/2] Fix PR gdb/19676: Internal error in linux-thread.db.c if /proc not mounted If /proc is not mounted, GDB fails an assertion in find_new_threads_once: Continuing. /home/pedro/gdb/mygit/src/gdb/linux-thread-db.c:1249: internal-error: find_new_threads_once: Assertion `!target_has_execution' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) That was supposed to catch misuses of td_ta_thr_iter, which is unsafe for live debugging. However, if /proc is not mounted, we still fallback to using it. I didn't bother with a warning, because GDB already prints several others related to failing to open /proc files. gdb/ChangeLog: 2016-03-01 Pedro Alves PR gdb/19676 * linux-thread-db.c (try_thread_db_load_1): Leave info->td_ta_thr_iter_p NULL iff debugging a live process and we have /proc access. (find_new_threads_once): Assert that we have a non-NULL info->td_ta_thr_iter_p instead of checking whether the target has execution. --- gdb/linux-thread-db.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/gdb/linux-thread-db.c b/gdb/linux-thread-db.c index 1eb457d..ce60beb 100644 --- a/gdb/linux-thread-db.c +++ b/gdb/linux-thread-db.c @@ -564,7 +564,6 @@ try_thread_db_load_1 (struct thread_db_info *info) /* These are essential. */ CHK (TDB_VERBOSE_DLSYM (info, td_ta_map_lwp2thr)); - CHK (TDB_VERBOSE_DLSYM (info, td_ta_thr_iter)); CHK (TDB_VERBOSE_DLSYM (info, td_thr_validate)); CHK (TDB_VERBOSE_DLSYM (info, td_thr_get_info)); @@ -572,10 +571,6 @@ try_thread_db_load_1 (struct thread_db_info *info) TDB_DLSYM (info, td_thr_tls_get_addr); TDB_DLSYM (info, td_thr_tlsbase); -#undef TDB_VERBOSE_DLSYM -#undef TDB_DLSYM -#undef CHK - /* It's best to avoid td_ta_thr_iter if possible. That walks data structures in the inferior's address space that may be corrupted, or, if the target is running, may change while we walk them. If @@ -587,6 +582,15 @@ try_thread_db_load_1 (struct thread_db_info *info) currently on core targets, as it uses ptrace directly. */ if (target_has_execution && linux_proc_task_list_dir_exists (ptid_get_pid (inferior_ptid))) + info->td_ta_thr_iter_p = NULL; + else + CHK (TDB_VERBOSE_DLSYM (info, td_ta_thr_iter)); + +#undef TDB_VERBOSE_DLSYM +#undef TDB_DLSYM +#undef CHK + + if (info->td_ta_thr_iter_p == NULL) { struct lwp_info *lp; int pid = ptid_get_pid (inferior_ptid); @@ -1246,7 +1250,7 @@ find_new_threads_once (struct thread_db_info *info, int iteration, data.new_threads = 0; /* See comment in thread_db_update_thread_list. */ - gdb_assert (!target_has_execution); + gdb_assert (info->td_ta_thr_iter_p != NULL); TRY { -- 2.5.0 http://sourceware.org/ml/gdb-patches/2016-03/msg00246.html Subject: [patch] Suggest running gdbserver for a PID in container --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, currently gdb -p will print: warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable BTW it is a bit lost in all the other messages. Full screen output is in: https://sourceware.org/bugzilla/show_bug.cgi?id=19828 It correctly states the problem but it does not say how to solve it. Is at least this little suggestion OK? Originally I wanted to suggest also the Docker "-p 1234:1234" parameter but I see the containers are more general topic than just Docker (even LxC etc.). According to Gary future GDBs should be able to work even without gdbserver. But currently gdbserver is still required. Thanks, Jan --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=1 gdb/ChangeLog 2016-03-15 Jan Kratochvil * linux-thread-db.c (check_pid_namespace_match): Extend the message. diff --git a/gdb/linux-thread-db.c b/gdb/linux-thread-db.c index 1eb457d..21166bf 100644 --- a/gdb/linux-thread-db.c +++ b/gdb/linux-thread-db.c @@ -1020,7 +1020,8 @@ check_pid_namespace_match (void) { warning (_ ("Target and debugger are in different PID " "namespaces; thread lists and other data are " - "likely unreliable")); + "likely unreliable. " + "Connect to gdbserver inside the container.")); } } } --azLHFNyN32YCQGCU-- commit fef3cb9f3aa84018d10866f89228ae3f23e5ca7e Author: Jan Kratochvil Date: Wed Apr 6 15:57:08 2016 +0200 Print the "file" command suggestion in exec_file_locate_attach currently: $ gdbserver-7.9 :1234 true & $ gdb -q -ex 'target remote :1234' # that -q is not relevant here Remote debugging using :1234 warning: Could not load vsyscall page because no executable was specified try using the "file" command first. 0x00007ffff7ddcc80 in ?? () (gdb) b main No symbol table is loaded. Use the "file" command. Make breakpoint pending on future shared library load? (y or [n]) _ Provide more suggestive message to use the "file" command. gdb/ChangeLog 2016-04-06 Jan Kratochvil Pedro Alves * exec.c (exec_file_locate_attach): Print warning for unsupported target_pid_to_exec_file. * symfile-mem.c (add_vsyscall_page): Remove the "file" command message part. ### a/gdb/ChangeLog ### b/gdb/ChangeLog ## -1,3 +1,11 @@ +2016-04-06 Jan Kratochvil + Pedro Alves + + * exec.c (exec_file_locate_attach): Print warning for unsupported + target_pid_to_exec_file. + * symfile-mem.c (add_vsyscall_page): Remove the "file" command + message part. + 2016-04-04 Simon Marchi * cli/cli-decode.c (help_cmd_list): Fix function doc and remove --- a/gdb/exec.c +++ b/gdb/exec.c @@ -151,7 +151,13 @@ exec_file_locate_attach (int pid, int from_tty) /* Try to determine a filename from the process itself. */ exec_file = target_pid_to_exec_file (pid); if (exec_file == NULL) - return; + { + warning (_("No executable has been specified and target does not " + "support\n" + "determining executable automatically. " + "Try using the \"file\" command.")); + return; + } /* If gdb_sysroot is not empty and the discovered filename is absolute then prefix the filename with gdb_sysroot. */ --- a/gdb/symfile-mem.c +++ b/gdb/symfile-mem.c @@ -214,8 +214,7 @@ add_vsyscall_page (struct target_ops *target, int from_tty) format should fix this. */ { warning (_("Could not load vsyscall page " - "because no executable was specified\n" - "try using the \"file\" command first.")); + "because no executable was specified")); return; } args.bfd = bfd;