aboutsummaryrefslogtreecommitdiff
path: root/gdb/objfiles.h
AgeCommit message (Collapse)AuthorFilesLines
5 daysgdb/progspace: link objfiles using owning_intrusive_listSimon Marchi1-1/+1
This simplifies things a little bit, removing some `find_if` when inserting or removing objfiles, and the whole unwrapping_objfile_iterator thing. Change-Id: Idd1851d36c7834820c9c1639a6a252de643eafba
2024-09-24[gdb/symtab] Don't expand non-Ada CUs for info exceptionsTom de Vries1-1/+3
I noticed when running test-case gdb.ada/info_exc.exp with glibc debug info installed, that the "info exceptions" command that lists all Ada exceptions also expands non-Ada CUs, which includes CUs in /lib64/ld-linux-x86-64.so.2 and /lib64/libc.so.6. Fix this by: - adding a new lang_matcher parameter to the expand_symtabs_matching function, and - using that new parameter in the expand_symtabs_matching call in ada_add_global_exceptions. The new parameter is a hint, meaning implementations are free to ignore it and expand CUs with any language. This is the case for partial symtabs, I'm not sure whether it makes sense to implement support for this there. Conversely, when processing a CU with language C and name "<artificial>" (as produced by GCC LTO), the CU may not really have a single language and we should ignore the lang_matcher. See also commit d2f67711730 ("Fix 'catch exception' with -flto"). Now that we have lang_matcher available, also use it to limit name splitting styles and symbol matchers to those applicable to the matched languages. Without this patch we have (with a gdb build with -O0): ... $ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null real 0m1.866s user 0m2.089s sys 0m0.120s ... and with this patch we have: ... $ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null real 0m0.469s user 0m0.777s sys 0m0.051s ... Or, to put it in terms of number of CUs, we have 1853 CUs: ... $ gdb -q -batch -readnow outputs/gdb.ada/info_exc/foo \ -ex start \ -ex "maint info symtabs" \ | grep -c " name " 1853 ... Without this patch, we have: ... $ gdb -q -batch outputs/gdb.ada/info_exc/foo \ -ex start \ -ex "info exceptions" \ -ex "maint info symtabs" \ | grep -c " name " 1393 ... so ~75% of the CUs is expanded, and with this patch we have: ... $ gdb <same-as-above> 20 ... so ~1% of the CUs is expanded. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR symtab/32182 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32182
2024-08-12gdb: drop struct keyword when using bound_minimal_symbolSimon Marchi1-5/+4
This is a simple find / replace from "struct bound_minimal_symbol" to "bound_minimal_symbol", to make things shorter and more consisten througout. In some cases, move variable declarations where first used. Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849 Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-07-15gdb: pass program space to objfile::makeSimon Marchi1-2/+3
Make the current program space reference bubble up one level. Change-Id: Iee8b11c853c76e539c991c4785737c69e6a1925c Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-07-15gdb: pass program space to objfile::objfileSimon Marchi1-1/+2
Make the current program space reference bubble up one level. Change-Id: I81e45e89e0cfd87c308f801d49ae811a941348b7 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-07-15gdb: pass program space to entry_point_addressSimon Marchi1-1/+3
Make the current program space reference bubble up one level. Change-Id: Ifc9b8186abaefb10caf99f79ae09e526fa65c882 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-07-15gdb: pass program space to entry_point_address_querySimon Marchi1-1/+5
Make the current program space bubble up one level. Change-Id: Ic3ad0869ca1afe41854f605a6f7eb092fca29ff8 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-07-15gdb: pass program space to objfiles_changedSimon Marchi1-1/+4
Make the current program space reference bubble up one level. Change-Id: I9b33c9e0d22c171eb1bb59ce480621b02c7b7bf7 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-07-15gdb: pass program space to have_{full,partial}_symbolsSimon Marchi1-8/+6
Make the current program space reference bubble up one level. Change-Id: I19c4fc2ca955f9c828ef426a077b43983865697b Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-07-15gdb: bool-ify a few functions in objfiles.{c,h}Simon Marchi1-5/+18
Change return types to bool, and make a few stylistic adjustments. Change-Id: I784c3c33af0394a77c25064b06eb3e128e69222f Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-07-15gdb: pass program space to objfile_purge_solibsSimon Marchi1-3/+3
Make the current program space reference bubble up one level. Change-Id: I08cfa77a0351c9602131ed2a294eabb1f1f59a6e Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-07-15gdb: use objfile::pspace in objfile::unlinkSimon Marchi1-1/+1
I think it would make sense to use objfile::pspace instead of the current program space here. It reduces the risks of calling this method with the wrong current program space set. Change-Id: Id4f3644719f232640c83a1c7f4aa92eaa6af6c5c Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-07-15gdb: make objfile::pspace privateSimon Marchi1-1/+6
Rename to m_pspace, add getter. An objfile's pspace never changes, so no setter is necessary. Change-Id: If4dfb300cb90dc0fb9776ea704ff92baebb8f626
2024-06-04Remove a couple unnecessary castsTom Tromey1-2/+2
After the previous bcache change, a couple of casts in objfiles.h are now redundant.
2024-05-16gdb: remove unused includes in objfiles.{c,h}Simon Marchi1-6/+0
Remove some includes reported as unused by clangd. Change-Id: I7768232c28b9b86b0a03628a1d15dede2b30c76a
2024-02-20Add obj_section::contains methodTom Tromey1-0/+6
I noticed a number of spots checking whether an address is in an obj_section. This patch introduces a new method for this and changes some code to use it. Regression tested on x86-64 Fedora 38. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-02-15Move lookup_name_info creation into basic_lookup_transparent_typeTom Tromey1-1/+2
I noticed that basic_lookup_transparent_type calls two different functions that both proceed to create a lookup_name_info. It's more efficient to create this object in the outermost layer possible. Making this change required a few related changes, resulting in this patch. There are still more changes of this sort that could be made. Regression tested on x86-64 Fedora 38.
2024-01-28Use domain_search_flags in lookup_symbol et alTom Tromey1-1/+1
This changes lookup_symbol and associated APIs to accept domain_search_flags rather than a domain_enum. Note that this introduces some new constants to Python and Guile. I chose to break out the documentation patch for this, because the internals here do not change until a later patch, and it seemed simpler to patch the docs just once, rather than twice.
2024-01-28Use domain_search_flags in lookup_global_symbol_languageTom Tromey1-3/+2
This changes quick_symbol_functions::lookup_global_symbol_language to accept domain_search_flags rather than just a domain_enum, and fixes up the fallout. To avoid introducing any regressions, any code passing VAR_DOMAIN now uses SEARCH_VFT. That is, no visible changes should result from this patch. However, it sets the stage to refine some searches later on.
2024-01-28Replace search_domain with domain_search_flagsTom Tromey1-1/+1
This patch changes gdb to replace search_domain with domain_search_flags everywhere. search_domain is removed.
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2024-01-08Remove two quick_symbol_functions methodsTom Tromey1-14/+0
quick_symbol_functions::read_partial_symbols is no longer implemented, so both it and quick_symbol_functions::can_lazily_read_symbols can be removed. This allows for other functions to be removed as well. Note that SYMFILE_NO_READ is now pretty much dead. I haven't removed it here -- but could if that's desirable. I tend to think that this functionality would be better implemented in the core; but whenever I dive into the non-DWARF readers it is pretty depressing.
2024-01-08Add quick_symbol_functions::compute_main_nameTom Tromey1-0/+3
This adds a new compute_main_name method to quick_symbol_functions. Currently there are no implementations of this, but a subsequent patch will add one.
2023-12-06Remove quick_symbol_functions::expand_matching_symbolsTom Tromey1-6/+0
The only caller of quick_symbol_functions::expand_matching_symbols was removed, so now this method and all implementations of it can be removed.
2023-11-14gdb: merge debug symbol file lookup code from coffread & elfread pathsAndrew Burgess1-0/+10
This commit merges the code that looks for and loads the separate debug symbol files from coffread.c and elfread.c. The factored out code is moved into a new objfile::find_and_add_separate_symbol_file() method. For the elfread.c path there should be no user visible changes after this commit. For the coffread.c path GDB will now attempt to perform a debuginfod lookup for the missing debug information, assuming that GDB can find a build-id in the COFF file. I don't know if COFF files can include a build-id, but I the existing coffread.c code already includes a call to find_separate_debug_file_by_build-id, so I know that it is at least OK for GDB to ask a COFF file for a build-id. If the COFF file doesn't include a build-id then the debuginfod lookup code will not trigger and the new code is harmless. If the COFF file does include a build-id, then we're going to end up asking debuginfod for the debug file. As build-ids should be unique, this should be harmless, even if debuginfod doesn't contain any suitable debug data, it just costs us one debuginfod lookup, so I'm not too worried about this for now. As with the previous commit, I've done some minimal testing using the mingw toolchain on a Linux machine, GDB seems to still access the split debug information just fine. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-20Remove explanatory comments from includesTom Tromey1-1/+1
I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-08-31[symtab/27831] Fix OBJF_MAINLINE assertKevin Buettner1-0/+11
This commit fixes a bug mentioned by Florian Weimer during the libpthread/ld.so load order discussion from 2021. Florian provided instructions for reproducing the bug here: https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html That particular test does some interesting things involving forks, threads, and thread local storage. Fortunately, none of that is needed to reproduce the problem. I've made a new test case (which is now found in a separate commit) contained in the files gdb.base/add-symbol-file-attach.{c,exp}. The .c file is fairly simple as is the recipe for reproducing the problem. After separately starting the test case and noting the process id, start gdb (w/ no arguments), and do the following to reproduce the assertion failure - for this run, the process id of the separately started add-symbol-file-attach process is 4103218: (gdb) add-symbol-file add-symbol-file-attach add symbol table from file "add-symbol-file-attach" (y or n) y Reading symbols from add-symbol-file-attach... (gdb) attach 4103218 Attaching to process 4103218 Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y Reading symbols from /tmp/add-symbol-file-attach... Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007f502130bf27 in pause () from /lib64/libc.so.6 (gdb) p foo symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*, const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. The add-symbol-file command causes the symbols to be loaded without the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being set. This, in turn, causes the "maybe_copied" flag to be set for the global symbol (named "foo" in the provided test case). The attach command will cause another objfile to be created, but it will reuse the symtabs from the objfile created by add-symbol-file, leading to a situation in which the OBJFILE_MAINLINE flag will be set for the new (attach-created) objfile, however the "maybe_copied" flag will still be set for the global symbol. Had it been loaded anew, this flag would not be set due to OBJFILE_MAINLINE being set for the objfile. At present, minimal_symbol::value_address looks like this: CORE_ADDR minimal_symbol::value_address (objfile *objfile) const { if (this->maybe_copied (objfile)) return get_msymbol_address (objfile, this); else return (CORE_ADDR (this->unrelocated_address ()) + objfile->section_offsets[this->section_index ()]); } So, we can now see the problem: When the "maybe_copied" flag is set, get_msymbol_address() will be called. However, get_msymbol_address() assumes that it won't be called with the OBF_MAINLINE flag set for the objfile in question. It, in fact, contains an assert() which makes sure that this is the case: gdb_assert ((objf->flags & OBJF_MAINLINE) == 0); (If this assert is removed, then get_msymbol_address() recurses infinitely for the case under consideration.) So, the problem here is that the maybe_copied flag is set for the symbol AND the OBJF_MAINLINE flag is set for the objfile. As noted earlier, this happens due to add-symbol-file being used; this causes the maybe_copied flag to be set. Later, when the attach is performed, OBJF_MAINLINE will be set for that objfile, leading to this unfortunate situation. My first cut at a solution involved adjusting the MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the method noted above) to include a test of the OBJFILE_MAINLINE flag. However, Simon Marchi, in his review of my patch, suggested a better solution. Simon observed that the 'maybe_copied' flag is (was, after this commit) being set/initialized in record_minimal_symbol() using using the objfile in the context in which the symbol was created. Simon further observed: Today, a single copy is created, as symtabs are shared between objfiles. This means that everything that we store into a symbol must be independent of any objfile. However, the value of the maybe_copied field is dependent on the objfile in the context of which the symbol was created. Meaning that when the symbol is re-used in the context of another objfile, the maybe_copied value is not right in the context of that objfile. So I think it means there isn't a single "is this symbol maybe copied" value, but instead "is this symbol maybe copied, in the context of this given objfile". And the answer is yes or no, depending on whether the objfile is mainline. So maybe_copied should become a method that takes an objfile and returns an answer based on that. Simon's full review can be found here: https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html Simon also provided a patch which implements this suggestion. The current patch is mostly his work, though I did make some adjustments during a rebase in addition to making some changes to account for a concern from Tom Tromey. During his review of the v3 series, Tom noted, "The old approach was specific to ELF, while the new approach will be used by any object format." Tom further observed, "...it seems like it could result in an incorrect evaluation in some scenario." This seemed plausible to me, so I introduced the flag 'object_format_has_copy_relocs' to struct objfile. It is set at the end of elf_symfile_read() in elfread.c. The minimal_symbol::maybe_copied method tests this new flag, forcing this method to return false when the flag is not set. If we find that other object file formats use the same copy reloc mechanism as ELF, then 'object_format_has_copy_relocs' should be set for objfiles using those formats. Lastly, I'll note that this is a strange use case. It's far more common to either let gdb figure out which file to load by itself when attaching, i.e. (gdb) attach 4104360 Attaching to process 4104360 Reading symbols from /tmp/add-symbol-file-attach... Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6 (gdb) p foo $1 = 42 ...or to use the "file" command prior to the attach, like this: (gdb) file add-symbol-file-attach Reading symbols from add-symbol-file-attach... (gdb) attach 4104360 Attaching to program: /tmp/add-symbol-file-attach, process 4104360 Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6 Both of these more common scenarios work perfectly fine; using "add-symbol-file" to load the program to which you will attach isn't recommended as a normal use case. That said, it's bad for gdb to assert, hence this fix. Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca> Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca> Approved-by: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
2023-08-18Remove most includes of psymtab.hTom Tromey1-1/+0
I found that most spots including psymtab.h do not need it. This patch removes these includes, and also one unnecessary include of psympriv.h.
2023-05-07Remove ALL_OBJFILE_OSECTIONSTom Tromey1-46/+107
This replaces ALL_OBJFILE_OSECTIONS with an iterator so that for-each can be used.
2023-05-07Rename objfile::sectionsTom Tromey1-10/+10
I think objfile::sections makes sense as the name of the method to iterate over an objfile's sections, so this patch renames the existing field to objfile::sections_start in preparation for that.
2023-01-20Use bool in pc_in_* functionsTom Tromey1-2/+2
I noticed that pc_in_unmapped_range had a weird return type -- it was returning a CORE_ADDR but intending to return a bool. This patch changes all the pc_in_* functions to return bool instead.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-08gdb: skip objfiles with no BFD in DWARF unwinderJan Vrany1-1/+3
While playing with JIT reader I experienced GDB to crash on null-pointer dereference when stepping through non-jitted code. The problem was that dwarf2_frame_find_fde () assumed that all objfiles have BFD but that's not always true. To address this problem, this commit skips such objfiles. To test the fix we put breakpoint in jit_function_add (). The JIT reader does not know how unwind this function so unwinding eventually falls back to DWARF unwinder which in turn iterates over objfiles. Since the the code is jitted, it is guaranteed it would eventually process JIT objfile. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-6/+3
Currently, every internal_error call must be passed __FILE__/__LINE__ explicitly, like: internal_error (__FILE__, __LINE__, "foo %d", var); The need to pass in explicit __FILE__/__LINE__ is there probably because the function predates widespread and portable variadic macros availability. We can use variadic macros nowadays, and in fact, we already use them in several places, including the related gdb_assert_not_reached. So this patch renames the internal_error function to something else, and then reimplements internal_error as a variadic macro that expands __FILE__/__LINE__ itself. The result is that we now should call internal_error like so: internal_error ("foo %d", var); Likewise for internal_warning. The patch adjusts all calls sites. 99% of the adjustments were done with a perl/sed script. The non-mechanical changes are in gdbsupport/errors.h, gdbsupport/gdb_assert.h, and gdb/gdbarch.py. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
2022-08-03Use unique_ptr to destroy per-bfd objectTom Tromey1-2/+7
In some cases, the objfile owns the per-bfd object. This is yet another object that can sometimes be destroyed before the registry is destroyed, possibly reslting in a use-after-free. Also, I noticed that the condition for deleting the object is not the same as the condition used to create it -- so it could possibly result in a memory leak in some situations. This patch fixes the problem by introducing a new unique_ptr that holds this object when necessary.
2022-08-03Use auto_obstack in objfileTom Tromey1-1/+1
This changes objfile to use an auto_obstack. This helps prevent use-after-free bugs, because it ensures that anything allocated on the objfile obstack will live past the point at which the registry object is destroyed.
2022-08-03Use gdb_bfd_ref_ptr in objfileTom Tromey1-6/+6
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to removing some manual memory management, this fixes a use-after-free that was introduced by the registry rewrite series. The issue there was that, in some cases, registry shutdown could refer to memory that had already been freed. This help fix the bug by delaying the destruction of the BFD reference (and thus the per-bfd object) until after the registry has been shut down.
2022-07-28Rewrite registry.hTom Tromey1-5/+1
This rewrites registry.h, removing all the macros and replacing it with relatively ordinary template classes. The result is less code than the previous setup. It replaces large macros with a relatively straightforward C++ class, and now manages its own cleanup. The existing type-safe "key" class is replaced with the equivalent template class. This approach ended up requiring relatively few changes to the users of the registry code in gdb -- code using the key system just required a small change to the key's declaration. All existing users of the old C-like API are now converted to use the type-safe API. This mostly involved changing explicit deletion functions to be an operator() in a deleter class. The old "save/free" two-phase process is removed, and replaced with a single "free" phase. No existing code used both phases. The old "free" callbacks took a parameter for the enclosing container object. However, this wasn't truly needed and is removed here as well.
2022-05-31Use unique_ptr for objfilesTom Tromey1-1/+1
A while back, I changed objfiles to be held via a shared_ptr. The idea at the time was that this was a step toward writing to the index cache in the background, and this would let gdb keep a reference alive to do so. However, since then we've rewritten the DWARF reader, and the new index can do this without requiring a shared pointer -- in fact there are patches pending to implement this. This patch switches objfile management to unique_ptr, which makes more sense now. Regression tested on x86-64 Fedora 34.
2022-05-26gdb: Require psymtab before calling quick_functions in objfileLancelot SIX1-0/+13
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
2022-05-05gdb: use gdb::function_view for ↵Simon Marchi1-3/+2
gdbarch_iterate_over_objfiles_in_search_order callback A rather straightforward patch to change an instance of callback + void pointer to gdb::function_view, allowing pasing lambdas that capture, and eliminating the need for the untyped pointer. Change-Id: I73ed644e7849945265a2c763f79f5456695b0037
2022-01-18Move gdb obstack code to gdbsupportTom Tromey1-1/+1
This moves the gdb-specific obstack code -- both extensions like obconcat and obstack_strdup, and things like auto_obstack -- to gdbsupport.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-10-18CTF: incorrect underlying type setting for enumeration typesWeimin Pan1-0/+5
A bug was filed against the incorrect underlying type setting for an enumeration type, which was caused by a copy and paste error. This patch fixes the problem by setting it by calling objfile_int_type, which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits. Also add error checking on ctf_func_type_info call.
2021-07-30Use iterator_range in more placesTom Tromey1-50/+9
This changes a couple of spots to replace custom iterator range classes with a specialization of iterator_range. Regression tested on x86-64 Fedora 34.
2021-07-06gdb: introduce iterator_range, remove next_adapterSimon Marchi1-4/+2
I was always a bit confused by next_adapter, because it kind of mixes the element type and the iterator type. In reality, it is not much more than a class that wraps two iterators (begin and end). However, it assumes that: - you can construct the begin iterator by passing a pointer to the first element of the iterable - you can default-construct iterator to make the end iterator I think that by generalizing it a little bit, we can re-use it at more places. Rename it to "iterator_range". I think it describes a bit better: it's a range made by wrapping a begin and end iterator. Move it to its own file, since it's not related to next_iterator anymore. iterator_range has two constructors. The variadic one, where arguments are forwarded to construct the underlying begin iterator. The end iterator is constructed through default construction. This is a generalization of what we have today. There is another constructor which receives already constructed begin and end iterators, useful if the end iterator can't be obtained by default-construction. Or, if you wanted to make a range that does not end at the end of the container, you could pass any iterator as the "end". This generalization allows removing some "range" classes, like all_inferiors_range. These classes existed only to pass some arguments when constructing the begin iterator. With iterator_range, those same arguments are passed to the iterator_range constructed and then forwarded to the constructed begin iterator. There is a small functional difference in how iterator_range works compared to next_adapter. next_adapter stored the pointer it received as argument and constructeur an iterator in the `begin` method. iterator_range constructs the begin iterator and stores it as a member. Its `begin` method returns a copy of that iterator. With just iterator_range, uses of next_adapter<foo> would be replaced with: using foo_iterator = next_iterator<foo>; using foo_range = iterator_range<foo_iterator>; However, I added a `next_range` wrapper as a direct replacement for next_adapter<foo>. IMO, next_range is a slightly better name than next_adapter. The rest of the changes are applications of this new class. gdbsupport/ChangeLog: * next-iterator.h (class next_adapter): Remove. * iterator-range.h: New. gdb/ChangeLog: * breakpoint.h (bp_locations_range): Remove. (bp_location_range): New. (struct breakpoint) <locations>: Adjust type. (breakpoint_range): Use iterator_range. (tracepoint_range): Use iterator_range. * breakpoint.c (breakpoint::locations): Adjust return type. * gdb_bfd.h (gdb_bfd_section_range): Use iterator_range. * gdbthread.h (all_threads_safe): Pass argument to all_threads_safe_range. * inferior-iter.h (all_inferiors_range): Use iterator_range. (all_inferiors_safe_range): Use iterator_range. (all_non_exited_inferiors_range): Use iterator_range. * inferior.h (all_inferiors, all_non_exited_inferiors): Pass inferior_list as argument. * objfiles.h (struct objfile) <compunits_range>: Remove. <compunits>: Return compunit_symtab_range. * progspace.h (unwrapping_objfile_iterator) <unwrapping_objfile_iterator>: Take parameter by value. (unwrapping_objfile_range): Use iterator_range. (struct program_space) <objfiles_range>: Define with "using". <objfiles>: Adjust. <objfiles_safe_range>: Define with "using". <objfiles_safe>: Adjust. <solibs>: Return so_list_range, define here. * progspace.c (program_space::solibs): Remove. * psymtab.h (class psymtab_storage) <partial_symtab_iterator>: New. <partial_symtab_range>: Use iterator_range. * solist.h (so_list_range): New. * symtab.h (compunit_symtab_range): New. (symtab_range): New. (compunit_filetabs): Change to a function. * thread-iter.h (inf_threads_range, inf_non_exited_threads_range, safe_inf_threads_range, all_threads_safe_range): Use iterator_range. * top.h (ui_range): New. (all_uis): Use ui_range. Change-Id: Ib7a9d2a3547f45f01aa1c6b24536ba159db9b854
2021-06-28gdb: convert obj_section macros to methodsSimon Marchi1-31/+62
Convert these three macros to methods of obj_section. The problem fixed by the following patch is caused by an out of bound access of the objfile::section_offsets vector. Since this is deep in macros, we don't get a clear backtrace and it's difficult to debug. Changing that to methods means we can step in them and break on them. Because their implementation requires knowing about struct objfile, move struct obj_section below struct objfile in objfiles.h. The obj_section_offset was used in one place as an lvalue to set offsets, in machoread.c. Replace that with a set_offset method. Add the objfile::section_offset and objfile::set_section_offset methods to improve encapsulation (reduce other objects poking into struct objfile's internals). gdb/ChangeLog: * objfiles.h (struct obj_section): Move down. <offset, set_offset, addr, endaddr>: New. (obj_section_offset, obj_section_addr, obj_section_endaddr), replace all users to use obj_section methods. (struct objfile) <section_offset, set_section_offset>: New. Change-Id: I97e8fcae93ab2353fbdadcb4a5ec10d7949a7334
2021-06-25gdb: add new function quick_symbol_functions::has_unexpanded_symbolsAndrew Burgess1-0/+6
Adds a new function to the quick_symbol_functions API to let us know if there are any unexpanded symbols. This functionality is required by a later commit. After this commit the functionality is unused, and untested. The new function objfile::has_unexpanded_symtabs is added to the symfile-debug.c file which is a little strange, but this is (currently) where many of the other objfile::* functions (that call onto the quick_symbol_functions) are defined, so I'm reluctant to break this pattern. There should be no user visible changes after this commit. gdb/ChangeLog: * dwarf2/read.c (struct dwarf2_base_index_functions) <has_unexpanded_symtabs>: Declare. (dwarf2_base_index_functions::has_unexpanded_symtabs): Define new function. * objfiles.h (struct objfile) <has_unexpanded_symtabs>: Declare. * psympriv.h (struct psymbol_functions) <has_unexpanded_symtabs>: Declare. * psymtab.c (psymbol_functions::has_unexpanded_symtabs): Define new function. * quick-symbol.h (struct quick_symbol_functions) <has_unexpanded_symtabs>: Declare. * symfile-debug.c (objfile::has_unexpanded_symtabs): Define new function.
2021-04-17Simplify quick_symbol_functions::map_matching_symbolsTom Tromey1-2/+1
quick_symbol_functions::map_matching_symbols is only used by the Ada code. Currently, it both expands certain psymtabs and then walks over the full symtabs -- including any already-expanded ones -- calling a callback. It appears to work lazily as well, in that if the callback returns false, iteration stops. However, only the psymtab implementation does this; the DWARF index implementations are not lazy. It turns out, though, that the only callback that is ever passed here never returns false. This patch simplifies this method by removing the callback. The method is also renamed. In the new scheme, the caller is responsible for walking the full symtabs, which removes some redundancy as well. gdb/ChangeLog 2021-04-17 Tom Tromey <tom@tromey.com> * psymtab.c (psymbol_functions::expand_matching_symbols): Rename from map_matching_symbols. Change parameters. * psympriv.h (struct psymbol_functions) <expand_matching_symbols>: Rename from map_matching_symbols. Change parameters. * dwarf2/read.c (struct dwarf2_gdb_index) <expand_matching_symbols>: Rename from map_matching_symbols. Change parameters. (struct dwarf2_debug_names_index) <expand_matching_symbols>: Rename from map_matching_symbols. Change parameters. (dwarf2_gdb_index::expand_matching_symbols): Rename from dw2_map_matching_symbols. Change parameters. (dwarf2_gdb_index::expand_matching_symbols): Remove old implementation. (dwarf2_debug_names_index::expand_matching_symbols): Rename from map_matching_symbols. Change parameters. * objfiles.h (struct objfile) <expand_matching_symbols>: Rename from map_matching_symbols. Change parameters. * symfile-debug.c (objfile::expand_matching_symbols): Rename from map_matching_symbols. Change parameters. * ada-lang.c (map_matching_symbols): New function. (add_nonlocal_symbols): Update.
2021-04-17Remove quick_symbol_functions::expand_symtabs_with_fullnameTom Tromey1-1/+5
This removes quick_symbol_functions::expand_symtabs_with_fullname, replacing it with a call to expand_symtabs_matching. As with the previous patches, the implementation is consolidated in the objfile method. gdb/ChangeLog 2021-04-17 Tom Tromey <tom@tromey.com> * quick-symbol.h (struct quick_symbol_functions) <expand_symtabs_with_fullname>: Remove. * psymtab.c (psymbol_functions::expand_symtabs_with_fullname): Remove. * psympriv.h (struct psymbol_functions) <expand_symtabs_with_fullname>: Remove. * dwarf2/read.c (struct dwarf2_base_index_functions) <expand_symtabs_with_fullname>: Remove. (dwarf2_base_index_functions::expand_symtabs_with_fullname): Remove. * objfiles.h (struct objfile) <expand_symtabs_with_fullname>: Update comment. * symfile-debug.c (objfile::expand_symtabs_with_fullname): Rewrite.
generated by cgit v1.1 at 2024-11-16 19:50:19 +0000