aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2
AgeCommit message (Collapse)AuthorFilesLines
2023-01-31gdb/dwarf: rename cooked_index_vector to cooked_indexSimon Marchi5-38/+35
See previous patch's commit message for rationale. Change-Id: I6b8cdc045dffccc1c01ed690ff258af09f6ff076 Approved-By: Tom Tromey <tom@tromey.com>
2023-01-31gdb/dwarf: rename cooked_index to cooked_index_shardSimon Marchi3-24/+24
I propose to rename cooked_index_vector and cooked_index such that the "main" object, that is the entry point to the index, is called cooked_index. The fact that the cooked index is implemented as a vector of smaller indexes is an implementation detail. This patch renames cooked_index to cooked_index_shard. The following patch renames cooked_index_vector to cooked_index. Change-Id: Id650f97dcb23c48f8409fa0974cd093ca0b75177 Approved-By: Tom Tromey <tom@tromey.com>
2023-01-31gdb: add nullptr check to cooked_index_functions::dumpSimon Marchi1-4/+5
Since commit 7d82b08e9e0a ("gdb/dwarf: dump cooked index contents in cooked_index_functions::dump"), we see: maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error^M ^M Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error: Objfile at 0x614000005040, bfd at 0x6120000e08c0, 15 minsyms^M ^M Cooked index in use:^M ^M /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb-checked-static-cast.h:58: internal-error: checked_static_cast: Assertion `result != nullptr' failed.^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M ----- Backtrace -----^M FAIL: gdb.dwarf2/dw2-error.exp: maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error (GDB internal error) The problem is that when cooked_index_functions fails to build an index, per_objfile->index_table is nullptr. Therefore, add a nullptr check, like other methods of cooked_index_functions already do. Print the "Cooked index in use" message after the nullptr check, such that if the cooked index failed to build, that message is not printed. Change-Id: Id67aef592e76c41b1e3bde9838a4e36cef873253
2023-01-30gdb: fix dwarf2/cooked-index.c compilation on 32-bit systemsSimon Marchi1-1/+1
The i386 builder shows: ../../binutils-gdb/gdb/dwarf2/cooked-index.c: In member function ‘void cooked_index_vector::dump(gdbarch*) const’: ../../binutils-gdb/gdb/dwarf2/cooked-index.c:492:40: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::__underlying_type_impl<sect_offset, true>::type’ {aka ‘long long unsigned int’} [-Werror=format=] 492 | gdb_printf (" DIE offset: 0x%lx\n", | ~~^ | | | long unsigned int | %llx 493 | to_underlying (entry->die_offset)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | std::__underlying_type_impl<sect_offset, true>::type {aka long long unsigned int} The die_offset's underlying type is uint64, so use PRIx64 in the format string. Change-Id: Ibdde4c624ed1bb50eced9a514a4e37aec70a1323
2023-01-30gdb/dwarf: dump cooked index contents in cooked_index_functions::dumpSimon Marchi3-1/+109
As I am investigating a crash I see with the cooked index, I thought it would be useful to have a way to dump the index contents. For those not too familiar with it (that includes me), it can help get a feel of what it contains and how it is structured. The cooked_index_functions::dump function is called as part of the "maintenance print objfiles" command. I tried to make the output well structured and indented to help readability, as this prints a lot of text. The dump function first dumps all cooked index entries, like this: [25] ((cooked_index_entry *) 0x621000121220) name: __ioinit canonical: __ioinit DWARF tag: DW_TAG_variable flags: 0x2 [IS_STATIC] DIE offset: 0x21a4 parent: ((cooked_index_entry *) 0x6210000f9610) [std] Then the information about the main symbol: main: ((cooked_index_entry *) 0x621000123b40) [main] And finally the address map contents: [1] ((addrmap *) 0x6210000f7910) [0x0] ((dwarf2_per_cu_data *) 0) [0x118a] ((dwarf2_per_cu_data *) 0x60c000007f00) [0x1cc7] ((dwarf2_per_cu_data *) 0) [0x1cc8] ((dwarf2_per_cu_data *) 0x60c000007f00) [0x1cdf] ((dwarf2_per_cu_data *) 0) [0x1ce0] ((dwarf2_per_cu_data *) 0x60c000007f00) The display of address maps above could probably be improved, to show it more as ranges, but I think this is a reasonable start. Note that this patch depends on Pedro Alves' patch "enum_flags to_string" [1]. If my patch is to be merged before Pedro's series, I will cherry-pick this patch from his series and merge it before mine. [1] https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-8-pedro@palves.net/ Change-Id: Ida13e479fd4c8d21102ddd732241778bc3b6904a
2023-01-30Fix comparator bug in cooked indexTom Tromey2-85/+132
Simon pointed out that the cooked index template-matching patch introduced a failure in libstdc++ debug mode. In particular, the new code violates the assumption of std::lower_bound and std::upper_bound that the range is sorted with respect to the comparison. When I first debugged this, I thought the problem was unfixable as-is and that a second layer of filtering would have to be done. However, on irc, Simon pointed out that it could perhaps be solved if the comparison function were assured that one operand always came from the index, with the other always being the search string. This patch implements this idea. First, a new mode is introduced: a sorting mode for cooked_index_entry::compare. In this mode, strings are compared case-insensitively, but we're careful to always sort '<' before any other printable character. This way, two names like "func" and "func<param>" will be sorted next to each other -- i.e., "func1" will not be seen between them. This is important when searching. Second, the compare function is changed to work in a strcmp-like way. This makes it easier to test and (IMO) understand. Third, the compare function is modified so that in non-sorting modes, the index entry is always the first argument. This allows consistency in compares. I regression tested this in libstdc++ debug mode on x86-64 Fedora 36. It fixes the crash that Simon saw. This is v2. I believe it addresses the review comments, except for the 'enum class' change, as I mentioned in email on the list. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-30Clean up lnp_state_machine constructorTom Tromey1-20/+13
This changes the lnp_state_machine constructor to initialize members directly; and changes lnp_state_machine itself to initialize members inline when possible. Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-01-30Make addrmap const-correct in cooked indexTom Tromey3-9/+11
After the cooked index is created, the addrmaps should be const. Change-Id: I8234520ab346ced40a8dd6e478ba21fc438c2ba2
2023-01-30gdb: provide const-correct versions of addrmap::find and addrmap::foreachSimon Marchi3-8/+9
Users of addrmap::find and addrmap::foreach that have a const addrmap should ideally receive const pointers to objects, to indicate they should not be modified. However, users that have a non-const addrmap should still receive a non-const pointer. To achieve this, without adding more virtual methods, make the existing find and foreach virtual methods private and prefix them with "do_". Add small non-const and const wrappers for find and foreach. Obviously, the const can be cast away, but if using static_cast instead of C-style casts, then the compiler won't let you cast the const away. I changed all the callers of addrmap::find and addrmap::foreach I could find to make them use static_cast. Change-Id: Ia8e69d022564f80d961413658fe6068edc71a094
2023-01-27More const-correctness in cooked indexerTom Tromey2-12/+13
I noticed that iterating over the index yields non-const cooked_index_entry objects. However, after finalization, they should not be modified. This patch enforces this by adding const where needed. v2 makes the find, all_entries, and wait methods const as well.
2023-01-25gdb: dwarf2 generic implementation for caching function dataTorbjörn SVENSSON2-2/+95
When there is no dwarf2 data for a register, a function can be called to provide the value of this register. In some situations, it might not be trivial to determine the value to return and it would cause a performance bottleneck to do the computation each time. This patch allows the called function to have a "cache" object that it can use to store some metadata between calls to reduce the performance impact of the complex logic. The cache object is unique for each function and frame, so if there are more than one function pointer stored in the dwarf2_frame_cache->reg array, then the appropriate pointer will be supplied (the type is not known by the dwarf2 implementation). dwarf2_frame_get_fn_data can be used to retrieve the function unique cache object. dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the function unique cache object. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
2023-01-20gdb: move frame_info_ptr to frame.{c,h}Simon Marchi1-1/+1
A patch later in this series will make frame_info_ptr access some fields internal to frame_info, which we don't want to expose outside of frame.c. Move the frame_info_ptr class to frame.h, and the definitions to frame.c. Remove frame-info.c and frame-info.h. Change-Id: Ic5949759e6262ea0da6123858702d48fe5673fea Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-01-20gdb: move call site types to call-site.hSimon Marchi8-7/+252
I hesitated between putting the file in the dwarf2 directory (as gdb/dwarf2/call-site.h) or in the common directory (as gdb/call-site.h). The concept of call site is not DWARF-specific, another debug info reader could provide this information. But as it is, the implementation is a bit DWARF-specific, as one form it can take is a DWARF expression and parameters can be defined using a DWARF register number. So I ended up choosing to put it under dwarf2/. If another debug info reader ever wants to provide call site information, we can introduce a layer of abstraction between the "common" call site and the "dwarf2" call site. The copyright start year comes from the date `struct call_site` was introduced. Change-Id: I1cd84aa581fbbf729edc91b20f7d7a6e0377014d Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-01-20gdb: move sect_offset and cu_offset to dwarf2/types.hSimon Marchi1-0/+39
I want to move the call_site stuff out of gdbtypes.h, to a new header file, to break some cyclic include problem. The call_site stuff uses cu_offset, also defined in gdbtypes.h, so cu_offset also needs to move somewhere else (otherwise, call-site.h will need to include gdbtypes.h, and we are back to square 1). I could move cu_offset to the future new file dwarf2/call-site.h, but it doesn't sound like a good place for it, at cu_offset is not specific to call sites, it's used throughout dwarf2/. So, move it to its own file, dwarf2/types.h. For now, gdbtypes.h includes dwarf2/types.h, but that will be removed once the call site stuff is moved to its own file. Move sect_offset with it too. sect_offset is not a DWARF-specific concept, but for the moment it is only used in dwarf2/. Change-Id: I1fd2a3b7b67dee789c4874244b044bde7db43d8e Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-01-20gdb/dwarf: fix UBsan crash in read_subrange_typeSimon Marchi1-10/+19
When running gdb.ada/arrayptr.exp (and others) on Ubuntu 22.04, with the `gnat-11` package installed (not `gnat`), with UBSan activated, I get: (gdb) break foo.adb:40 /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:17689:20: runtime error: shift exponent 127 is too large for 64-bit type 'long unsigned int' The problematic DIEs are: 0x00001460: DW_TAG_subrange_type DW_AT_lower_bound [DW_FORM_data1] (0x00) DW_AT_upper_bound [DW_FORM_data16] (ffffffffffffffff3f00000000000000) DW_AT_name [DW_FORM_strp] ("foo__packed_array___XP7___XDLU_0__1180591620717411303423") DW_AT_type [DW_FORM_ref4] (0x0000153f "long_long_long_unsigned") DW_AT_GNAT_descriptive_type [DW_FORM_ref4] (0x0000147e) DW_AT_artificial [DW_FORM_flag_present] (true) 0x0000153f: DW_TAG_base_type DW_AT_byte_size [DW_FORM_data1] (0x10) DW_AT_encoding [DW_FORM_data1] (DW_ATE_unsigned) DW_AT_name [DW_FORM_strp] ("long_long_long_unsigned") DW_AT_artificial [DW_FORM_flag_present] (true) When processed by this code: negative_mask = -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1)); if (low.kind () == PROP_CONST && !base_type->is_unsigned () && (low.const_val () & negative_mask)) low.set_const_val (low.const_val () | negative_mask); When the base type's length (16 bytes in this case) is larger than a ULONGEST (typically 8 bytes), the bit shift is too large. My obvious fix is just to skip the fixup for base types larger than a ULONGEST (8 bytes). I don't think we really handle constant attribute values larger than 8 bytes anyway, so this is part of a much larger problem. Add a test that replicates this situation, but uses bounds that fit in a signed 64 bit, so we get a sensible result. Change-Id: I8d0a24f3edd83b44e0761a0ce38922d3e2e112fb Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29386
2023-01-17Fix parameter-less template regression in new DWARF readerTom Tromey3-22/+139
PR c++/29896 points out a regression in the new DWARF reader. It does not properly handle a case like "break fn", where "fn" is a template function. This happens because the new index uses strncasecmp to compare. However, to make this work correctly, we need a custom function that ignores template parameters. This patch adds a custom comparison function and fixes the bug. A new test case is included. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29896
2023-01-17Move hash_entry and eq_entry into cooked_index::do_finalizeTom Tromey1-20/+14
I was briefly confused by the hash_entry and eq_entry functions in the cooked index. They are only needed in a single method, and that method already has a couple of local lambdas for a different hash table. So, it seemed cleaner to move these there as well.
2023-01-17Don't erase empty indices in DWARF readerTom Tromey1-10/+0
The DWARF reader has some code to remove empty indices. However, I think this code has been obsolete since some earlier changes to parallel_for_each. This patch removes this code.
2023-01-10gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.Rohr, Stephan1-3/+0
The 'rw_pieced_value' function is executed when fetching a (lazy) variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'. The function checks the 'type' and 'enclosing_type' fields of the value for identity. * The 'type' field describes the type of a value. * In most cases, the 'enclosing_type' field is identical to the 'type' field. * Scenarios where the 'type' and 'enclosing_type' of an object differ are described in 'gdb/value.c'. Possible cases are: * If a value represents a C++ object, then the 'type' field gives the object's compile-time type. If the object actually belongs to some class derived from `type', perhaps with other base classes and additional members, then `type' is just a subobject of the real thing, and the full object is probably larger than `type' would suggest. * If 'type' is a dynamic class (i.e. one with a vtable), then GDB can actually determine the object's run-time type by looking at the run-time type information in the vtable. GDB may then elect to read the entire object. * If the user casts a variable to a different type (e.g. 'print (<type> []) <variable>'), the value's type is updated before reading the value. If a lazy value is fetched, GDB allocates space based on the enclosing type's length and typically reads the 'full' object. This is not implemented for pieced values and causes an internal error if 'type' and 'enclosing_type' of a value are not identical. However, GDB can read the value based on its type. Thus, this patch fixes the previously mentioned cases by removing the check for identity. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28605 gdb/ChangeLog: 2022-04-13 Stephan Rohr <stephan.rohr@intel.com> * dwarf2/loc.c (rw_pieced_value): Fix check on 'type' and 'enlcosing_type' when reading pieced value 'v'. gdb/testsuite/ChangeLog: 2022-04-13 Stephan Rohr <stephan.rohr@intel.com> * gdb.dwarf2/shortpiece.exp: Added test cases.
2023-01-03Don't let property evaluation affect the current languageTom Tromey1-0/+5
On PPC, we saw that calling an inferior function could sometimes change the current language, because gdb would select the call dummy frame -- associated with _start. This patch changes gdb so that the current language is never affected by DWARF property evaluation.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker46-46/+46
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-30[gdb/symtab] Make comp_unit_head.length privateTom de Vries3-18/+33
Make comp_unit_head.length private, to enforce using accessor functions. Replace accessor function get_length with get_length_with_initial and get_length_without_initial, to make it explicit which variant we're using. Tested on x86_64-linux. PR symtab/29343 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343
2022-12-26Add initializers to comp_unit_headTom Tromey4-16/+14
PR symtab/29343 points out that it would be beneficial if comp_unit_head had a constructor and used initializers. This patch implements this. I'm unsure if this is sufficient to close the bug, but at least it's a step. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343
2022-12-23Use bool for dwarf2_has_infoTom Tromey2-5/+5
This changes dwarf2_has_info to return bool.
2022-12-21gdb/c++: validate 'using' directives based on the current lineBruno Larsen1-1/+28
When asking GDB to print a variable from an imported namespace, we only want to see variables imported in lines that the inferior has already gone through, as is being tested last in gdb.cp/nsusing.exp. However with the proposed change to gdb.cp/nsusing.exp, we get the following failures: (gdb) PASS: gdb.cp/nsusing.exp: continue to breakpoint: marker10 stop print x $9 = 911 (gdb) FAIL: gdb.cp/nsusing.exp: print x, before using statement next 15 y += x; (gdb) PASS: gdb.cp/nsusing.exp: using namespace M print x $10 = 911 (gdb) PASS: gdb.cp/nsusing.exp: print x, only using M Showing that the feature wasn't functioning properly, it just so happened that gcc ordered the namespaces in a convenient way. This happens because GDB doesn't take into account the line where the "using namespace" directive is written. So long as it shows up in the current scope, we assume it is valid. To fix this, add a new member to struct using_direct, that stores the line where the directive was written, and a new function that informs if the using directive is valid already. Unfortunately, due to a GCC bug, the failure still shows up. Compilers that set the declaration line of the using directive correctly (such as Clang) do not show such a bug, so the test includes an XFAIL for gcc code. Finally, because the final test of gdb.cp/nsusing.exp has turned into multiple that all would need XFAILs for older GCCs (<= 4.3), and that GCC is very old, if it is detected, the test just exits early. Approved-by: Tom Tromey <tom@tromey.com>
2022-12-19Use bool constants for value_print_optionsTom Tromey1-1/+1
This changes the uses of value_print_options to use 'true' and 'false' rather than integers.
2022-12-08gdb: skip objfiles with no BFD in DWARF unwinderJan Vrany1-0/+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-12-01Add name canonicalization for CTom Tromey2-3/+23
PR symtab/29105 shows a number of situations where symbol lookup can result in the expansion of too many CUs. What happens is that lookup_signed_typename will try to look up a type like "signed int". In cooked_index_functions::expand_symtabs_matching, when looping over languages, the C++ case will canonicalize this type name to be "int" instead. Then this method will proceed to expand every CU that has an entry for "int" -- i.e., nearly all of them. A crucial component of this is that the caller, objfile::lookup_symbol, does not do this canonicalization, so when it tries to find the symbol for "signed int", it fails -- causing the loop to continue. This patch fixes the problem by introducing name canonicalization for C. The idea here is that, by making C and C++ agree on the canonical name when a symbol name can have multiple spellings, we avoid the bad behavior in objfile::lookup_symbol (and any other such code -- I don't know if there is any). Unlike C++, C only has a few situations where canonicalization is needed. And, in particular, due to the lack of overloading (thus avoiding any issues in linespec) and due to the way c-exp.y works, I think that no canonicalization is needed during symbol lookup -- only during symtab construction. This explains why lookup_name_info is not touched. The stabs reader is modified on a "best effort" basis. The DWARF reader needed one small tweak in dwarf2_name to avoid a regression in dw2-unusual-field-names.exp. I think this is adequately explained by the comment, but basically this is a scenario that should not occur in real code, only the gdb test suite. lookup_signed_typename is simplified. It used to search for two different type names, but now gdb can search just for the canonical form. gdb.dwarf2/enum-type.exp needed a small tweak, because the canonicalizer turns "unsigned integer" into "unsigned int integer". It seems better here to use the correct C type name. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105 Tested-by: Simon Marchi <simark@simark.ca> Reviewed-by: Andrew Burgess <aburgess@redhat.com>
2022-12-01Refactor cooked_index::do_finalizeTom Tromey1-26/+23
This refactors cooked_index::do_finalize, reordering an 'if' to make it a little less redundant. This change makes a subsequent patch easier to read. Reviewed-by: Andrew Burgess <aburgess@redhat.com>
2022-12-01Remove language check from dwarf2_compute_nameTom Tromey1-5/+3
dwarf2_compute_name has a redundant check of the CU's language -- this is also checked in dwarf2_canonicalize_name. Removing this slightly simplifies a future patch. Reviewed-by: Andrew Burgess <aburgess@redhat.com>
2022-12-01gdb/dwarf: add some QUIT macrosSimon Marchi1-0/+4
While testing the fix for PR 29105, I noticed I couldn't ctrl-C my way out of GDB expanding many symtabs. GDB was busy in a loop in cooked_index_functions::expand_symtabs_matching. Add a QUIT there. I also happened to see a spot in cooked_index_functions::expand_matching_symbols where a QUIT would be useful too, since we iterate over a potentially big number of index entries and expand CUs in the loop. Add one there too. Change-Id: Ie1d650381df7f944c16d841b3e592d2dce7306c3 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-27Fix leak in the dwarf readerPhilippe Waroquiers1-1/+1
Valgrind reports a leak in the dwarf reader (see details below). The function dw2_get_file_names_reader is interning in the per_objfile all the file names it finds, except the name of 'fnd file name and directory'. Instead, it was xstrdup-ing the name. Fix the leaks by also interning the name. This was validated running the tests natively, and under valgrind. Leaks have decreased as mentionned below. Valgrind detected no error such as double free or use after free. Stack trace of the leak: ==4113266== 490,735 bytes in 17,500 blocks are definitely lost in loss record 7,061 of 7,074 ==4113266== at 0x483979B: malloc (vg_replace_malloc.c:393) ==4113266== by 0x25A454: xmalloc (alloc.c:57) ==4113266== by 0x7D1E1E: xstrdup (xstrdup.c:34) ==4113266== by 0x39D141: dw2_get_file_names_reader (read.c:2825) ==4113266== by 0x39D141: dw2_get_file_names(dwarf2_per_cu_data*, dwarf2_per_objfile*) (read.c:2851) ==4113266== by 0x39DD6C: dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) (read.c:4149) ==4113266== by 0x3BC8B5: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18688) ==4113266== by 0x5DD1EA: objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) (symfile-debug.c:207) ==4113266== by 0x5F04CC: iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) (symtab.c:633) ==4113266== by 0x477EE3: collect_symtabs_from_filename(char const*, program_space*) (linespec.c:3712) ==4113266== by 0x477FC1: symtabs_from_filename(char const*, program_space*) (linespec.c:3726) ==4113266== by 0x47A9B8: convert_explicit_location_spec_to_linespec(linespec_state*, linespec*, char const*, char const*, symbol_name_match_type, char const*, line_offset) (linespec.c:2329) ==4113266== by 0x47E86E: convert_explicit_location_spec_to_sals (linespec.c:2388) ==4113266== by 0x47E86E: location_spec_to_sals(linespec_parser*, location_spec const*) (linespec.c:3104) ==4113266== by 0x47EDAC: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3149) ... Without the fix, the top 10 leaks are: ./gdb/testsuite/outputs/gdb.base/condbreak-bad/gdb.log:345:==3213924== definitely lost: 130,937 bytes in 5,409 blocks ./gdb/testsuite/outputs/gdb.base/hbreak2/gdb.log:619:==3758919== definitely lost: 173,323 bytes in 7,204 blocks ./gdb/testsuite/outputs/gdb.mi/mi-var-cp/gdb.log:1320:==4152873== definitely lost: 172,826 bytes in 7,207 blocks ./gdb/testsuite/outputs/gdb.base/advance-until-multiple-locations/gdb.log:398:==2992643== definitely lost: 172,965 bytes in 7,211 blocks ./gdb/testsuite/outputs/gdb.mi/mi-var-cmd/gdb.log:2302:==4159476== definitely lost: 173,129 bytes in 7,211 blocks ./gdb/testsuite/outputs/gdb.cp/gdb2384/gdb.log:222:==3811851== definitely lost: 218,106 bytes in 7,761 blocks ./gdb/testsuite/outputs/gdb.cp/mb-templates/gdb.log:310:==3787344== definitely lost: 290,311 bytes in 10,340 blocks ./gdb/testsuite/outputs/gdb.mi/mi-var-rtti/gdb.log:2568:==4158350== definitely lost: 435,427 bytes in 15,507 blocks ./gdb/testsuite/outputs/gdb.mi/mi-catch-cpp-exceptions/gdb.log:1704:==4119722== definitely lost: 435,405 bytes in 15,510 blocks ./gdb/testsuite/outputs/gdb.mi/mi-vla-fortran/gdb.log:768:==4113266== definitely lost: 508,585 bytes in 18,109 blocks With the fix: ./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1536:==2924193== indirectly lost: 13,848 bytes in 98 blocks ./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1675:==2928777== indirectly lost: 13,848 bytes in 98 blocks ./gdb/testsuite/outputs/gdb.python/py-inferior-leak/gdb.log:4729:==3353335== definitely lost: 3,360 bytes in 140 blocks ./gdb/testsuite/outputs/gdb.base/kill-detach-inferiors-cmd/gdb.log:210:==2746927== indirectly lost: 13,246 bytes in 154 blocks ./gdb/testsuite/outputs/gdb.base/inferior-clone/gdb.log:179:==3034984== indirectly lost: 12,921 bytes in 161 blocks ./gdb/testsuite/outputs/gdb.base/interrupt-daemon/gdb.log:209:==3006248== indirectly lost: 20,683 bytes in 174 blocks ./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:714:==3512403== indirectly lost: 20,707 bytes in 175 blocks ./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:962:==3514498== indirectly lost: 20,851 bytes in 178 blocks ./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:336:==2585839== indirectly lost: 53,630 bytes in 386 blocks ./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:1338:==2592417== indirectly lost: 100,008 bytes in 1,154 blocks Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-26[gdb/symtab] Handle failure to open .gnu_debugaltlink fileTom de Vries1-1/+10
If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after dwz has created it, with test-case gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m we run into: ... (gdb) file access-mem-running-thread-exit^M Reading symbols from access-mem-running-thread-exit...^M could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M ... followed a bit later by: ... (gdb) file access-mem-running-thread-exit^M Reading symbols from access-mem-running-thread-exit...^M gdb/dwarf2/read.c:7284: internal-error: create_all_units: \ Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M ... The problem is that create_units does not catch the error thrown by dwarf2_get_dwz_file. Fix this by catching the error and performing the necessary cleanup, getting the same result for the first and second file command. PR symtab/29805 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805
2022-11-26Fix jump on uninit producer_is_clang bit of cu.h dwarf2_cu struct.Philippe Waroquiers1-0/+1
Valgrind reports a "jump on unitialised bit error" when running e.g. gdb.base/macro-source-path.exp (see details below). Fix this by initializing producer_is_clang member variable of dwarf2_cu. Tested on amd64/debian11 and re-running gdb.base/macro-source-path.exp under valgrind. ==2140965== Conditional jump or move depends on uninitialised value(s) ==2140965== at 0x5211F7: dwarf_decode_macro_bytes(dwarf2_per_objfile*, buildsym_compunit*, bfd*, unsigned char const*, unsigned char const*, macro_source_file*, line_header const*, dwarf2_section_info const*, int, int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, htab*, dwarf2_cu*) (macro.c:676) ==2140965== by 0x52158A: dwarf_decode_macros(dwarf2_per_objfile*, buildsym_compunit*, dwarf2_section_info const*, line_header const*, unsigned int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, int, dwarf2_cu*) (macro.c:967) ==2140965== by 0x523BC4: dwarf_decode_macros(dwarf2_cu*, unsigned int, int) (read.c:23379) ==2140965== by 0x552AB5: read_file_scope(die_info*, dwarf2_cu*) (read.c:9687) ==2140965== by 0x54F7B2: process_die(die_info*, dwarf2_cu*) (read.c:8660) ==2140965== by 0x5569C7: process_full_comp_unit (read.c:8429) ==2140965== by 0x5569C7: process_queue (read.c:7675) ==2140965== by 0x5569C7: dw2_do_instantiate_symtab (read.c:2063) ==2140965== by 0x5569C7: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085) ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984) ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781) ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276) .... ==2140965== Uninitialised value was created by a heap allocation ==2140965== at 0x4839F01: operator new(unsigned long) (vg_replace_malloc.c:434) ==2140965== by 0x533A64: cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) (read.c:6264) ==2140965== by 0x5340C2: load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool, language) (read.c:7729) ==2140965== by 0x548338: load_cu(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2021) ==2140965== by 0x55634C: dw2_do_instantiate_symtab (read.c:2048) ==2140965== by 0x55634C: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085) ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984) ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781) ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276) ....
2022-11-26remove the declared but undefined/unused method find_partial_diePhilippe Waroquiers1-2/+0
The method struct partial_die_info *find_partial_die (sect_offset sect_off); in cu.h is defined, but is used nowhere and not implemented.
2022-11-14PowerPC, fix support for printing the function return value for non-trivial ↵Carl Love2-8/+13
values. Currently, a non-trivial return value from a function cannot currently be reliably determined on PowerPC. This is due to the fact that the PowerPC ABI uses register r3 to store the address of the buffer containing the non-trivial return value when the function is called. The PowerPC ABI does not guarantee the value in register r3 is not modified in the function. Thus the value in r3 cannot be reliably used to obtain the return addreses on exit from the function. This patch adds a new gdbarch method to allow PowerPC to access the value of r3 on entry to a function. On PowerPC, the new gdbarch method attempts to use the DW_OP_entry_value for the DWARF entries, when exiting the function, to determine the value of r3 on entry to the function. This requires the use of the -fvar-tracking compiler option to compile the user application thus generating the DW_OP_entry_value in the binary. The DW_OP_entry_value entries in the binary file allows GDB to resolve the DW_TAG_call_site entries. This new gdbarch method is used to get the return buffer address, in the case of a function returning a nontrivial data type, on exit from the function. The GDB function should_stop checks to see if RETURN_BUF is non-zero. By default, RETURN_BUF will be set to zero by the new gdbarch method call for all architectures except PowerPC. The get_return_value function will be used to obtain the return value on all other architectures as is currently being done if RETURN_BUF is zero. On PowerPC, the new gdbarch method will return a nonzero address in RETURN_BUF if the value can be determined. The value_at function uses the return buffer address to get the return value. This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp. The correct function return values are now reported. Note this patch is dependent on patch: "PowerPC, function ppc64_sysv_abi_return_value add missing return value convention". This patch has been tested on Power 10 and x86-64 with no regressions.
2022-11-03gdb: Fix issue with Clang CLI macrosBruno Larsen5-6/+33
Clang up to version 15 (current) adds macros that were defined in the command line or by "other means", according to the Dwarf specification, after the last DW_MACRO_end_file, instead of before the first DW_MACRO_start_file, as the specification dictates. When GDB reads the macros after the last file is closed, the macros never end up "in scope" and so we can't print them. This has been submitted as a bug to Clang developers (https://github.com/llvm/llvm-project/issues/54506), and PR macros/29034 was opened for GDB to keep track of this. Seeing as there is no expected date for it to be fixed, add a workaround for all current versions of Clang. The workaround detects when the main file would be closed and if the producer is Clang, and turns that operation into a noop, so we keep a reference to the current_file as those macros are read. A test case was added to confirm the functionality, and the KFAIL for running gdb.base/macro-source-path when using clang. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29034 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-10-28Convert compunit_language to a methodTom Tromey1-2/+2
This changes compunit_language to be a method on compunit_symtab. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-10-25gdb: remove spurious spaces after frame_info_ptrSimon Marchi2-4/+4
Fix some whitespace issues introduced with the frame_info_ptr patch. Change-Id: I158d30d8108c97564276c647fc98283ff7b12163
2022-10-21gdb: make inherit_abstract_dies use vector iteratorsSimon Marchi1-13/+12
Small cleanup to use std::vector iterators rather than raw pointers. Approved-By: Tom Tromey <tom@tromey.com> Change-Id: I8d50dbb3f2d8dad7ff94066a578d523f1f31b590
2022-10-21gdb: check for empty offsets vector in inherit_abstract_diesSimon Marchi1-9/+14
When building GDB with clang and --enable-ubsan, I get: UNRESOLVED: gdb.dwarf2/frame-inlined-in-outer-frame.exp: starti prompt The cause being: $ ./gdb --data-directory=data-directory -nx -q -readnow testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame Reading symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame... Expanding full symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame... /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer I found this to happen with ld-linux on at least Arch Linux and Ubuntu 22.04: $ ./gdb --data-directory=data-directory -nx -q -readnow -iex "set debuginfod enabled on" /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/ld-linux-x86-64.so.2... Reading symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo... Expanding full symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo... /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer The problem happens when doing this: sect_offset *offsetp = offsets.data () + 1 When `offsets` is an empty vector, `offsets.data ()` returns nullptr. Fix it by wrapping that in a `!offsets.empty ()` check. Change-Id: I6d29ba2fe80ba4308f68effd9c57d4ee8d67c29f Approved-By: Tom Tromey <tom@tromey.com>
2022-10-21Fix incorrect .gdb_index with new DWARF scannerTom Tromey3-8/+34
PR symtab/29694 points out a regression caused by the new DWARF scanner when the cc-with-gdb-index target board is used. What happens here is that an older version of gdb will make an index describing the "A" type as: [737] A: 1 [global, type] whereas the new gdb says: [1008] A: 0 [global, type] Here the old one is correct because the A in CU 0 is just a declaration without a size: <1><45>: Abbrev Number: 10 (DW_TAG_structure_type) <46> DW_AT_name : A <48> DW_AT_declaration : 1 <48> DW_AT_sibling : <0x6d> This patch fixes the problem by introducing the idea of a "type declaration". I think gdb still needs to recurse into these types, searching for methods, but by marking the type itself as a declaration, gdb can skip this type during lookups and when writing the index. Regression tested on x86-64 using the cc-with-gdb-index board. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29694
2022-10-21Fix bug in Ada packed array handlingTom Tromey1-0/+4
A user found a bug where an array of packed arrays was printed incorrectly. The bug here is that the packed array has a bit stride, but the outer array does not -- and should not. However, update_static_array_size does not distinguish between an array of packed arrays and a multi-dimensional packed array, and for the latter, only the innermost array will end up with a stride. This patch fixes the problem by adding a flag to indicate whether a given array type is a constituent of a multi-dimensional array.
2022-10-21gdb: declare variables on first use in inherit_abstract_diesSimon Marchi1-28/+23
Move variable declarations to where they are first use, plus some random style fixes. Change-Id: Idf40d60f9034996fa6a234165cd989a721eb4148
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves5-30/+19
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-10-17Remove a nullptr check in DWARF scannerTom Tromey1-1/+0
In scan_attributes, The DWARF scanner checks whether maybe_defer is nullptr, but this can never happen. This patch removes the check.
2022-10-17Change .gdb_index de-duplication implementationTom Tromey1-36/+41
While investigating PR symtab/29179, I found that one Ada test failed because, although a certain symbol was present in the index, with the new DWARF reader it pointed to a different CU than was chosen by earlier versions of gdb. This patch changes how symbol de-duplication is done, deferring the process until the entire symbol table has been constructed. This way, it's possible to always choose the lower-numbered CU among duplicates, which is how gdb (implicitly) previously worked. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179
2022-10-17Improve Ada support in .gdb_indexTom Tromey1-9/+35
The cooked index work changed how .gdb_index is constructed, and in the process broke .gdb_index support. This is PR symtab/29179. This patch partially fixes the problem. It arranges for Ada names to be encoded in the form expected by the index code. In particular, linkage names for Ada are emitted, including the "main" name; names are Ada-encoded; and names are no longer case-folded, something that prevented operator names from round-tripping correctly. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179
2022-10-17Don't add type linkage names to cooked indexTom Tromey1-5/+0
The compiler will sometimes emit a linkage name for a type, like: <1d3> DW_AT_linkage_name: (indirect string, offset: 0x106f): 11__mbstate_t These names aren't very useful, and this patch changes the DWARF reader so that they are ignored by the cooked index.
2022-10-17Fix regression in c-linkage-name.exp with gdb indexTom Tromey1-3/+4
c-linkage-name.exp started failing with the gdb-index target board due to an earlier patch. The problem here is that some linkage names must be in the index -- but, based on inspection, not C++ linkage names. This patch updates the code to exclude only these.
generated by cgit v1.1 at 2024-11-24 17:48:43 +0000