aboutsummaryrefslogtreecommitdiff
path: root/gdb/objfiles.h
diff options
context:
space:
mode:
authorLancelot SIX <lancelot.six@amd.com>2022-05-24 13:32:18 +0100
committerLancelot SIX <lancelot.six@amd.com>2022-05-26 19:01:42 +0100
commitfcf8e814206f9f5a0a90b2f509fe12d841fa5163 (patch)
tree44ebd9d28b5d8c427805a976c074bc1d735c7572 /gdb/objfiles.h
parent834eaf9201c18efc5b888f3cd116dd7856bec759 (diff)
downloadfsf-binutils-gdb-fcf8e814206f9f5a0a90b2f509fe12d841fa5163.zip
fsf-binutils-gdb-fcf8e814206f9f5a0a90b2f509fe12d841fa5163.tar.gz
fsf-binutils-gdb-fcf8e814206f9f5a0a90b2f509fe12d841fa5163.tar.bz2
gdb: Require psymtab before calling quick_functions in objfile
The recent DWARF indexer rewrite introduced a regression when debugging a forking program. Here is a way to reproduce the issue (there might be other ways, but one is enough and this one mimics the situation we encountered). Consider a program which forks, and the child loads a shared library and calls a function in this shared library: if (fork () == 0) { void *solib = dlopen (some_solib, RTLD_NOW); void (*foo) () = dlsym (some_solib, "foo"); foo (); } Suppose that this program is compiled without debug info, but the shared library it loads has debug info enabled. When debugging such program with the following options: - set detach-on-fork off - set follow-fork-mode child we see something like: (gdb) b foo Function "foo" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (foo) pending. (gdb) run Starting program: a.out [Attaching after process 19720 fork to child process 19723] [New inferior 2 (process 19723)] [Switching to process 19723] Thread 2.1 "a.out" hit Breakpoint 1, 0x00007ffff7fc3101 in foo () from .../libfoo.so (gdb) list Fatal signal: Segmentation fault ----- Backtrace ----- 0x55a278f77d76 gdb_internal_backtrace_1 ../../gdb/bt-utils.c:122 0x55a278f77f83 _Z22gdb_internal_backtracev ../../gdb/bt-utils.c:168 0x55a27940b83b handle_fatal_signal ../../gdb/event-top.c:914 0x55a27940bbb1 handle_sigsegv ../../gdb/event-top.c:987 0x7effec0343bf ??? /build/glibc-sMfBJT/glibc-2.31/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x55a27924c9d3 _ZNKSt15__uniq_ptr_implI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE6_M_ptrEv /usr/include/c++/9/bits/unique_ptr.h:154 0x55a279248bc9 _ZNKSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE3getEv /usr/include/c++/9/bits/unique_ptr.h:361 0x55a2792ae718 _ZN27dwarf2_base_index_functions23find_last_source_symtabEP7objfile ../../gdb/dwarf2/read.c:3164 0x55a279afb93e _ZN7objfile23find_last_source_symtabEv ../../gdb/symfile-debug.c:139 0x55a279aa3040 _Z20select_source_symtabP6symtab ../../gdb/source.c:365 0x55a279aa22a1 _Z34set_default_source_symtab_and_linev ../../gdb/source.c:268 0x55a27903c44c list_command ../../gdb/cli/cli-cmds.c:1185 0x55a279051233 do_simple_func ../../gdb/cli/cli-decode.c:95 0x55a27905f221 _Z8cmd_funcP16cmd_list_elementPKci ../../gdb/cli/cli-decode.c:2514 0x55a279c3b0ba _Z15execute_commandPKci ../../gdb/top.c:660 0x55a27940a6c3 _Z15command_handlerPKc ../../gdb/event-top.c:598 0x55a27940b032 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE ../../gdb/event-top.c:797 0x55a279caf401 tui_command_line_handler ../../gdb/tui/tui-interp.c:278 0x55a279409098 gdb_rl_callback_handler ../../gdb/event-top.c:230 0x55a279ed5df2 rl_callback_read_char ../../../readline/readline/callback.c:281 0x55a279408bd8 gdb_rl_callback_read_char_wrapper_noexcept ../../gdb/event-top.c:188 0x55a279408de7 gdb_rl_callback_read_char_wrapper ../../gdb/event-top.c:205 0x55a27940a061 _Z19stdin_event_handleriPv ../../gdb/event-top.c:525 0x55a27a23771e handle_file_event ../../gdbsupport/event-loop.cc:574 0x55a27a237f5f gdb_wait_for_event ../../gdbsupport/event-loop.cc:700 0x55a27a235d81 _Z16gdb_do_one_eventv ../../gdbsupport/event-loop.cc:237 0x55a2796c2ef0 start_event_loop ../../gdb/main.c:418 0x55a2796c3217 captured_command_loop ../../gdb/main.c:478 0x55a2796c717b captured_main ../../gdb/main.c:1340 0x55a2796c7217 _Z8gdb_mainP18captured_main_args ../../gdb/main.c:1355 0x55a278d0b381 main ../../gdb/gdb.c:32 --------------------- A fatal error internal to GDB has been detected, further debugging is not possible. GDB will now terminate. This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. The first issue observed is in the message printed when hitting the breakpoint. It says that there was a break in the .so file as if there was no debug info associated with it, but there is. Later, if we try to display the source where the execution stopped, we have a segfault. Note that not having the debug info on the main binary is not strictly required to encounter some issues, it only is to encounter the segfault. If the main binary has debug information, GDB shows some source form the main binary, unrelated to where we stopped. The core of the issue is that GDB never loads the psymtab for the library. It is not loaded when we first see the .so because in case of detach-on-fork off, follow-fork-mode child, infrun.c sets child_inf->symfile_flags = SYMFILE_NO_READ to delay the psymtab loading as much as possible. If we compare to what was done to handle this before the new indexer was activated, the psymatb construction for the shared library was done under psymbol_functions::expand_symtabs_matching: bool psymbol_functions::expand_symtabs_matching (...) { for (partial_symtab *ps : require_partial_symbols (objfile)) ... } The new indexer's expand_symtabs_matching callback does not have a call to the objfile's require_partial_symbols, so if the partial symbol table is not loaded at this point, there is no mechanism to fix this. Instead of requiring each implementation of the quick_functions to check that partial symbols have been read, I think it is safer to enforce this when calling the quick functions. The general pattern for calling the quick functions is: for (auto *iter : qf) iter->the_actual_method_call (...) This patch proposes to wrap the access of the `qf` field with an accessor which ensures that partial symbols have been read before iterating: qf_require_partial_symbols. All calls to quick functions are updated except: - quick_functions::dump - quick_functions::read_partial_symbols (from objfile::require_partial_symbols) - quick_functions::can_lazily_read_symbols and quick_functions::has_symbols (from objfile::has_partial_symbols) Regression tested on x86_64-gnu-linux. Change-Id: I39a13a937fdbaae613a5cf68864b021000554546
Diffstat (limited to 'gdb/objfiles.h')
-rw-r--r--gdb/objfiles.h13
1 files changed, 13 insertions, 0 deletions
diff --git a/gdb/objfiles.h b/gdb/objfiles.h
index cb7a135..9da12ff 100644
--- a/gdb/objfiles.h
+++ b/gdb/objfiles.h
@@ -612,6 +612,19 @@ public:
this->section_offsets[idx] = offset;
}
+private:
+
+ /* Ensure that partial symbols have been read and return the "quick" (aka
+ partial) symbol functions for this symbol reader. */
+ const std::forward_list<quick_symbol_functions_up> &
+ qf_require_partial_symbols ()
+ {
+ this->require_partial_symbols (true);
+ return qf;
+ }
+
+public:
+
/* The object file's original name as specified by the user,
made absolute, and tilde-expanded. However, it is not canonicalized
(i.e., it has not been passed through gdb_realpath).