aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2
AgeCommit message (Collapse)AuthorFilesLines
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.
2022-10-16More uses of checked_static_castTom Tromey1-10/+10
This patch changes a few more uses of static_cast to use checked_static_cast. In this patch, cast-to-references are converted by moving the dereference outside of the cast, as checked_static_cast only handles pointers.
2022-10-16Use checked_static_cast in more placesTom Tromey1-7/+7
I looked through all the uses of static_cast<... *> in gdb and converted many of them to checked_static_cast. I couldn't test a few of these changes.
2022-10-10Change GDB to use frame_info_ptrTom Tromey8-83/+87
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-10-08Merge both implementations of debug_names::insertTom Tromey1-27/+24
The class debug_names has two 'insert' overloads, but only one of them is ever called externally, and it simply forwards to the other implementation. It seems cleaner to me to have a single method, so this patch merges the two.
2022-10-06[gdb/symtab] Factor out have_complaintTom de Vries1-14/+17
After committing 8ba677d3560 ("[gdb/symtab] Don't complain about function decls") I noticed that quite a bit of code in read_func_scope is used to decide whether to issue the "cannot get low and high bounds for subprogram DIE at $hex" complaint, which executes unnecessarily if we have the default "set complaints 0". Fix this by (NFC): - factoring out new static function have_complaint from macro complaint, and - using it to wrap the relevant code in read_func_scope. Tested on x86_64-linux.
2022-10-04[gdb/symtab] Don't complain about function declsTom de Vries1-1/+3
[ Requires "[gdb/symtab] Don't complain about inlined functions" as submitted here ( https://sourceware.org/pipermail/gdb-patches/2022-September/191762.html ). ] With the test-case included in this patch, we get: ... (gdb) ptype main^M During symbol reading: cannot get low and high bounds for subprogram DIE \ at 0xc1^M type = int (void)^M (gdb) FAIL: gdb.dwarf2/anon-ns-fn.exp: ptype main without complaints ... The DIE causing the complaint is a function declaration: ... <2><c1>: Abbrev Number: 3 (DW_TAG_subprogram) <c2> DW_AT_name : foo <c8> DW_AT_declaration : 1 ... which is referred to from the DIE representing the function definition: ... <1><f4>: Abbrev Number: 7 (DW_TAG_subprogram) <f5> DW_AT_specification: <0xc1> <f9> DW_AT_low_pc : 0x4004c7 <101> DW_AT_high_pc : 0x7 ... which does contain the low and high bounds. Fix this by not complaining about function declarations. Tested on x86_64-linux.
2022-10-04[gdb/symtab] Don't complain about inlined functionsTom de Vries1-1/+8
With the test-case included in this patch, we get: ... (gdb) ptype main^M During symbol reading: cannot get low and high bounds for subprogram DIE \ at 0x113^M During symbol reading: cannot get low and high bounds for subprogram DIE \ at 0x11f^M type = int (void)^M (gdb) FAIL: gdb.dwarf2/inline.exp: ptype main ... The complaints are about foo, with DW_AT_inline == DW_INL_inlined: ... <1><11f>: Abbrev Number: 6 (DW_TAG_subprogram) <120> DW_AT_name : foo <126> DW_AT_prototyped : 1 <126> DW_AT_type : <0x10c> <12a> DW_AT_inline : 1 (inlined) ... and foo2, with DW_AT_inline == DW_INL_declared_inlined: ... <1><113>: Abbrev Number: 5 (DW_TAG_subprogram) <114> DW_AT_name : foo2 <11a> DW_AT_prototyped : 1 <11a> DW_AT_type : <0x10c> <11e> DW_AT_inline : 3 (declared as inline and inlined) ... Fix this by not complaining about inlined functions. Tested on x86_64-linux.
2022-09-22[gdb/symtab] Add all_comp_units/all_type_units views on all_unitsTom de Vries3-11/+32
Add all_comp_units/all_type_units views on all_units. Having the views allows us to: - easily get the number of CUs or TUs in all_units, and - easily access the nth CU or TU. This minimizes the use of tu_stats.nr_tus. Tested on x86_64-linux.
2022-09-22[gdb/symtab] Rename all_comp_units to all_unitsTom de Vries3-87/+87
Mechanically rename all_comp_units to all_units: ... $ sed -i 's/all_comp_units/all_units/' gdb/dwarf2/* ... Tested on x86_64-linux.
2022-09-21gdbsupport: change path_join parameter to array_view<const char *>Simon Marchi1-2/+2
When a GDB built with -D_GLIBCXX_DEBUG=1 reads a binary with a single character name, we hit this assertion failure: $ ./gdb -q --data-directory=data-directory -nx ./x /usr/include/c++/12.1.0/string_view:239: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with _CharT = char; _Traits = std::char_traits<char>; const_reference = const char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed. The backtrace: #3 0x00007ffff6c0f002 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60 #4 0x000055555da8a864 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffcc30, __pos=1) at /usr/include/c++/12.1.0/string_view:239 #5 0x00005555609dcb88 in path_join[abi:cxx11](gdb::array_view<std::basic_string_view<char, std::char_traits<char> > const>) (paths=...) at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:203 #6 0x000055555e0443f4 in path_join<char const*, char const*> () at /home/simark/src/binutils-gdb/gdb/../gdbsupport/pathstuff.h:84 #7 0x00005555609dc336 in gdb_realpath_keepfile[abi:cxx11](char const*) (filename=0x6060000a8d40 "/home/simark/build/binutils-gdb-one-target/gdb/./x") at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:122 #8 0x000055555ebd2794 in exec_file_attach (filename=0x7fffffffe0f9 "./x", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:471 #9 0x000055555f2b3fb0 in catch_command_errors (command=0x55555ebd1ab6 <exec_file_attach(char const*, int)>, arg=0x7fffffffe0f9 "./x", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:513 #10 0x000055555f2b7e11 in captured_main_1 (context=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1209 #11 0x000055555f2b9144 in captured_main (data=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1319 #12 0x000055555f2b9226 in gdb_main (args=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1344 #13 0x000055555d938c5e in main (argc=5, argv=0x7fffffffdcf8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32 The problem is this line in path_join: gdb_assert (strlen (path) == 0 || !IS_ABSOLUTE_PATH (path)); ... where `path` is "x". IS_ABSOLUTE_PATH eventually calls HAS_DRIVE_SPEC_1: #define HAS_DRIVE_SPEC_1(dos_based, f) \ ((f)[0] && ((f)[1] == ':') && (dos_based)) This macro accesses indices 0 and 1 of the input string. However, `f` is a string_view of length 1, so it's incorrect to try to access index 1. We know that the string_view's underlying object is a null-terminated string, so in practice there's no harm. But as far as the string_view is concerned, index 1 is considered out of bounds. This patch makes the easy fix, that is to change the path_join parameter from a vector of to a vector of `const char *`. Another solution would be to introduce a non-standard gdb::cstring_view class, which would be a view over a null-terminated string. With that class, it would be correct to access index 1, it would yield the NUL character. If there is interest in having this class (it has been mentioned a few times in the past) I can do it and use it here. This was found by running tests such as gdb.ada/arrayidx.exp, which produce 1-char long filenames, so adding a new test is not necessary. Change-Id: Ia41a16c7243614636b18754fd98a41860756f7af
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi4-48/+48
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: add type::length / type::set_lengthSimon Marchi1-26/+18
Add the `length` and `set_length` methods on `struct type`, in order to remove the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi2-24/+23
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-09-21gdb: add type::target_type / type::set_target_typeSimon Marchi1-7/+6
Add the `target_type` and `set_target_type` methods on `struct type`, in order to remove the `TYPE_TARGET_TYPE` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. Change-Id: I85ce24d847763badd34fdee3e14b8c8c14cb3161
2022-09-17[gdb/symtab] Fix "file index out of range" complaintTom de Vries1-10/+10
With the test-case included in this commit, we run into this FAIL: ... (gdb) p var^M During symbol reading: file index out of range^M $1 = 0^M (gdb) FAIL: gdb.dwarf2/dw2-no-code-cu.exp: p var with no complaints ... This is a regression since commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), which contains this change in read_file_scope: ... - handle_DW_AT_stmt_list (die, cu, fnd, lowpc); + if (lowpc != highpc) + handle_DW_AT_stmt_list (die, cu, fnd, lowpc); ... The change intends to avoid a problem with a check in lnp_state_machine::check_line_address, but also prevents the file and dir tables from being read, which causes the complaint. Fix the FAIL by reducing the scope of the "lowpc != highpc" condition to the call to dwarf_decode_lines in handle_DW_AT_stmt_list. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29561
2022-09-16[gdb/symtab] Handle named DW_TAG_unspecified_type DIETom de Vries1-0/+1
With the test-case included in the patch, we run into: ... (gdb) info types -q std::nullptr_t^M During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'^M ^M File /usr/include/c++/7/x86_64-suse-linux/bits/c++config.h:^M 2198: typedef decltype(nullptr) std::nullptr_t;^M (gdb) FAIL: gdb.dwarf2/nullptr_t.exp: info types -q std::nullptr_t \ without complaint ... Fix the complaint by handling DW_TAG_unspecified_type in new_symbol, and verify in the test-case using "maint print symbols" that the symbol exists. Tested on x86_64-linux, with gcc 7.5.0 and clang 13.0. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17271
2022-09-12[gdb/symtab] Support .gdb_index section with TUs in .debug_infoTom de Vries1-2/+5
The .gdb_index variant of commit d878bb39e41 ("[gdb/symtab] Support .debug_names section with TUs in .debug_info"). Tested on x86_64-linux.
2022-09-11[gdb/symtab] Fix handling of DW_TAG_unspecified_typeTom de Vries1-3/+3
Currently, the test-case contained in this patch fails: ... (gdb) p (int) foo ()^M Invalid cast.^M (gdb) FAIL: gdb.dwarf2/dw2-unspecified-type.exp: p (int) foo () ... because DW_TAG_unspecified_type is translated as void. There's some code in read_unspecified_type that marks the type as stub, but that's only active for ada: ... if (cu->lang () == language_ada) type->set_is_stub (true); ... Fix this by: - marking the type as a stub for all languages, and - handling the stub return type case in call_function_by_hand_dummy. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29558
generated by cgit v1.1 at 2025-02-28 04:48:15 +0000