Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status
aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.dwarf2
Commit message (Collapse)AuthorAgeFilesLines
* [gdb/testsuite] Add gdb.dwarf2/dw2-tu-dwarf-4-5.expTom de Vries2024-11-273-0/+173
| | | | | | | | Add a regression test for PR symtab/32225. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225
* [gdb/contrib] Add two rules in common-misspellings.txtTom de Vries2024-11-235-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Eli mentioned [1] that given that we use US English spelling in our documentation, we should use "behavior" instead of "behaviour". In wikipedia-common-misspellings.txt there's a rule: ... behavour->behavior, behaviour ... which leaves this as a choice. Add an overriding rule to hardcode the choice to common-misspellings.txt: ... behavour->behavior ... and add a rule to rewrite behaviour into behavior: ... behaviour->behavior ... and re-run spellcheck.sh on gdb*. Tested on x86_64-linux. [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html
* gdb/build-id: protect against weirdly short build-idsAndrew Burgess2024-11-211-0/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While looking at build_id_to_bfd_suffix (in gdb/build-id.c) I realised that GDB would likely not do what we wanted if a build-id was ever a single byte. Right now, build-ids generated by the GNU linker are 32 bytes, but there's nothing that forces this to be the case, it's pretty easy to create a fake, single byte, build-id. Given that the build-id is an external input (read from the objfile), GDB should protect itself against these edge cases. The problem with build_id_to_bfd_suffix is that this function creates the path used to lookup either the debug information, or an executable, based on its build-id. So a 3-byte build-id 0xaabbcc will look in the path: `$DEBUG_FILE_DIRECTORY/.build-id/aa/bbcc.debug`. However, a single byte build-id 0xaa, will look in the file: `$DEBUG_FILE_DIRECTORY/.build-id/aa/.debug` which doesn't seem right. Worse, when looking for an objfile given a build-id GDB will look for a file called `$DEBUG_FILE_DIRECTORY/.build-id/aa/` with a trailing '/' character. I propose that, in build_id_to_bfd_suffix we just return early if the build-id is 1 byte (or less) with a return value that indicates no separate file was found. For testing I made use of the DWARF assembler. I needed to update the build-id creation proc, the existing code assumes that the build-id is a multiple of 4 bytes, so I added some additional padding to ensure that the generated note was a multiple of 4 bytes, even if the build-id was not. I added a test with a 1 byte build-id, and also for the case where the build-id has zero length. The zero length case already does what you'd expect (no debug is loaded) as the bfd library rejects the build-id when loading it from the objfile, but adding this additional test is pretty cheap. Approved-By: Kevin Buettner <kevinb@redhat.com>
* [gdb/contrib] Add "doens't->doesn't" to common-misspellings.txtTom de Vries2024-11-131-2/+2
| | | | | | | | | Add "doens't->doesn't" to gdb/contrib/common-misspellings.txt, and run gdb/contrib/spellcheck.sh to fix this in a few files. Tested on x86_64-linux. Approved-by: Kevin Buettner <kevinb@redhat.com>
* gdb: stepping between inline functions with multiple rangesBernd Edlinger2024-11-134-0/+616
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I (Andrew) have split this small change from a larger patch which was posted here: https://inbox.sourceware.org/gdb-patches/AS1PR01MB9465608EBD5D62642C51C428E4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com And I have written the stand alone test for this issue. The original patch included this paragraph to explain this change (I've fixed one typo in this text replacing 'program' with 'function'): ... it may happen that the infrun machinery steps from one inline range to another inline range of the same inline function. That can look like jumping back and forth from the calling function to the inline function, while really the inline function just jumps from a hot to a cold section of the code, i.e. error handling. The important thing that happens here is that both the outer function and the inline function must both have multiple ranges. When the inferior is within the inline function and moves from one range to another it is critical that the address we stop at is the start of a range in both the outer function and the inline function. The diagram below represents how the functions are split and aligned: (A) (B) bar: |------------| |---| foo: |------------------| |--------| The inferior is stepping through 'bar' and eventually reaches point (A) at which point control passes to point (B). Currently, when the inferior stops, GDB notices that both 'foo' and 'bar' start at address (B), and so GDB uses the inline frame mechanism to skip 'bar' and tells the user that the inferior is in 'foo'. However, as we were in 'bar' before the step then it makes sense that we should be in 'bar' after the step, and this is what the patch does. There are two tests using the DWARF assembler, the first checks the above situation and ensures that GDB reports 'bar' after the step. The second test is similar, but after the step we enter a new range where a different inline function starts, something like this: (A) (B) bar: |------------| baz: |---| foo: |------------------| |--------| In this case as we step at (A) and land at (B) we leave 'bar' and expect to stop in 'foo', GDB shouldn't automatically enter 'baz' as that is a completely different inline function. And this is, indeed, what we see. Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
* gdb: fix handling of DW_AT_entry_pc of inlined subroutinesAndrew Burgess2024-11-132-0/+534
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The entry PC for a DIE, e.g. an inline function, might not be the base address of the DIE. Currently though, in block::entry_pc(), GDB always returns the base address (low-pc or the first address of the first range) as the entry PC. This commit extends the block class to carry the entry PC as a separate member variable. Then the DWARF reader is extended to read and set the entry PC for the block. Now in block::entry_pc(), if the entry PC has been set, this is the value returned. If the entry-pc has not been set to a specific value then the old behaviour of block::entry_pc() remains, GDB will use the block's base address. Not every DIE will set the entry-pc, but GDB still needs to have an entry-pc for every block, so the existing logic supplies the entry-pc for any block where the entry-pc was not set. The DWARF-5 spec for reading the entry PC is a super-set of the spec as found in DWARF-4. For example, if there is no DW_AT_entry_pc then DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base address, which is DW_AT_low_pc or the first address in the first range specified by DW_AT_ranges if there is no DW_AT_low_pc. I have taken the approach of just implementing the DWARF-5 spec for everyone. There doesn't seem to be any benefit to deliberately ignoring a ranges based entry PC value for DWARF-4. If some naughty compiler has emitted that, then lets use it. Similarly, DWARF-4 says that DW_AT_entry_pc is an address. DWARF-5 allows an address or a constant, where the constant is an offset from the base address. I allow both approaches for all DWARF versions. There doesn't seem to be any downsides to this approach. I ran into an issue when testing this patch where GCC would have the DW_AT_entry_pc point to an empty range. When GDB parses the ranges any empty ranges are ignored. As a consequence, the entry-pc appears to be outside the address range of a block. The empty range problem is certainly something that we can, and should address, but that is not the focus of this patch, so for now I'm ignoring that problem. What I have done is added a check: if the DW_AT_entry_pc is outside the range of a block then the entry-pc is ignored, GDB will then fall-back to its default algorithm for computing the entry-pc. If/when in the future we address the empty range problem, these DW_AT_entry_pc attributes will suddenly become valid and GDB will start using them. Until then, GDB continues to operate as it always has. An early version of this patch stored the entry-pc within the block like this: std::optional<CORE_ADDR> m_entry_pc; However, a concern was raised that this, on a 64-bit host, effectively increases the size of block by 16-bytes (8-bytes for the CORE_ADDR, and 8-bytes for the std::optional's bool plus padding). If we remove the std::optional part and just use a CORE_ADDR then we need to have a "special" address to indicate if m_entry_pc is in use or not. I don't really like using special addresses; different targets can access different address ranges, even zero is a valid address on some targets. However, Bernd Edlinger suggested storing the entry-pc as an offset, and I think that will resolve my concerns. So, we store the entry-pc as a signed offset from the block's base address (the first address of the first range, or the start() address value if there are now ranges). Remember, ranges can be out of order, in which case the first address of the first range might be greater than the entry-pc. When GDB needs to read the entry-pc we can add the offset onto the blocks base address to recalculate it. With this done, on a 64-bit host, block only needs to increase by 8-bytes. The inline-entry.exp test was originally contributed by Bernd here: https://inbox.sourceware.org/gdb-patches/AS1PR01MB94659E4D9B3F4A6006CC605FE4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com though I have made some edits, making more use of lib/gdb.exp functions, making the gdb_test output patterns a little tighter, and updating the test to run with Clang. I also moved the test to gdb.opt/ as that seemed like a better home for it. Co-Authored-By: Bernd Edlinger <bernd.edlinger@hotmail.de>
* gdb/dwarf2/read.c: Handle empty CU nameLancelot SIX2024-11-112-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I recently came across a case where a compiler would emit a CU with an empty name. In such case, the attribute object constructed by GDB will return nullptr when as_string is called. One place is not checking for this possibility. As a result, loading such binary results in a GDB crash: $ gdb -q a.out Reading symbols from a.out... Fatal signal: Segmentation fault ----- Backtrace ----- [...] 0x742f4dd8afab __strcmp_avx2 ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 0x58593704a0bc prepare_one_comp_unit ../../gdb/dwarf2/read.c:21842 0x585937053fd9 process_psymtab_comp_unit ../../gdb/dwarf2/read.c:4633 0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_ ../../gdb/dwarf2/read.c:4943 [...] --------------------- 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/>. Segmentation fault (core dumped) This seems to be a regression introduced by the following commit: commit 00105aa1c4d9933fe3cfe9bc1be0daefe9f8ca36 Date: Tue Sep 24 10:24:22 2024 +0200 [gdb/symtab] Don't expand non-Ada CUs for info exceptions This patch fixes this issue by checking if attr->as_string returns nullptr. Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c Approved-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
* Add dw2-aranges.expAlexandra Hájková2024-11-082-0/+64
| | | | | | | | | | | | | | | | | | | | | | This test checks that GDB is able to load DWARF information when .debug_aranges has a section address size that is set to 0. This test was originally written by Jan Kratochvil to test commit 927aa2e778d from 2017, titled "DWARF-5: .debug_names index consumer". This test was originally written using a static .S file and has been present in the Fedora tree for a long time. If dwarf2/aranges.c is modified to turn off the address_size check, GDB will crash with SIGFPE when loading the executable with address size set to zero. I modified the DWARF assembler to make it possible to set the address size to zero in a .debug_aranges section and used the DWARF assembler to produce the assembly file. Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
* [gdb/symtab] Handle multiple .debug_info sectionsTom de Vries2024-10-292-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling dw2-multiple-debug-info.c using -gdwarf-5 -fdebug-types-section, we end with two .debug_info sections in the object file: ... $ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \ -gdwarf-5 \ -fdebug-types-section $ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info [10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8 [12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8 ... One of them contains the CU for dw2-multiple-debug-info.c, the other contains the TU for the type of variable a. When trying to print the type of variable a, we get: ... $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" 'a' has unknown type; cast it to its declared type ... because the TU hasn't been read. Fix this by adding support for reading multiple .debug_info sections, similar to how that is done for multiple .debug_types sections, getting us instead: ... $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" type = class sp1::A { ... } ... Tested on x86_64-linux. PR symtab/32223 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223
* [gdb/testsuite] Fix gdb.dwarf2/dwp-symlink.exp with target board fission-dwpTom de Vries2024-10-261-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two test-cases that only run when the target board produces .dwp files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp. When running those test-cases with target board fission-dwp, I run into: ... (gdb) ptype main^M warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \ referenced by CU at offset 0xa6 [in module dwp-symlink]^M type = <unknown return type> ()^M (gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink ... coming from: ... # This case cannot work. gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink" ... I had a bit of difficulty understanding what the test-case does/tries to do, so to build some understanding I reproduced the behaviour outside of the test-case: ... $ cat start.c void _start (void) {} $ gcc -gsplit-dwarf start.c -nostdlib $ gdb -q -batch a.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ dwp -e a.out $ rm start.dwo $ gdb -q -batch a.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ ln -s a.out b.out $ gdb -q -batch b.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ mv a.out.dwp b.out.dwp $ gdb -q -batch b.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ gdb -q -batch a.out -ex "print _start" During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ referenced by CU at offset 0x0 [in module a.out] warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ referenced by CU at offset 0x0 [in module a.out] $1 = {<text variable, no debug info>} 0x400144 <_start> ... and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp, and there's no way to find b.out.dwp starting from a.out. The fact that a FAIL is produced is incorrect, gdb does nothing wrong. Fix this by checking for the warning text instead. While we're at it, fix this PATH as well: ... (gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M (gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \ /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink PATH: gdb.dwarf2/dwp-symlink.exp: cd \ /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink ... While we're at it, use string_to_regexp to simplify the test-case. Tested on x86_64-linux, with target board fission-dwp.
* gdb/testsuite: introduce dwarf5 option to gdb_compileGuinevere Larsen2024-10-232-3/+2
| | | | | | | | | | | | | | | A few tests on the testsuite require dwarf5 to work. Up until now, the way to do this was to explicitly add the command line flag -gdwarf-5. This isn't very portable, in case a compiler requires a different flag to emit dwarf5. This commit adds a new option to gdb_compile that would be able to add the correct flag (if known) or error out in case we are unable to tell which flag to use. It also changes the existing tests to use this general option instead of hard coding -gdwarf-5. Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
* [gdb/testsuite] Handle maint set dwarf synchronous off defaultTom de Vries2024-10-222-2/+14
| | | | | | | | | | | | | I ran the testsuite with a patch setting dwarf_synchronous to false by default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did not show up as a result of the file command. Fix this by forcing "maint set dwarf synchronous on". Add the same in gdb.base/index-cache.exp, where this is also required. Tested on aarch64-linux.
* [gdb/testsuite] Improve class name in gdb.dwarf2/self-spec.expTom de Vries2024-10-221-3/+3
| | | | | | | | | | | | | | | | I ran into: ... (gdb) pipe maint print objfiles self-spec | grep c1^M name: c1^M canonical: c1^M qualified: c1^M [3] ((addrmap *) 0xfffedfc1f010)^M (gdb) FAIL: gdb.dwarf2/self-spec.exp: class c1 in cooked index ... Fix this by renaming the class from c1 to class1. Tested on aarch64-linux.
* [gdb/symtab] Fix incorrect filenames with inter-CU refsTom de Vries2024-10-211-0/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With target board unix we get: ... $ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \ -ex "info function operator\*" All functions matching regular expression "operator\*": File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc: 72: void foo::operator*(foo&); 85: void foo::operator*=(foo&); ... but with target board cc-with-dwz-m: ... All functions matching regular expression "operator\*": File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h: 72: void foo::operator*(foo&); 85: void foo::operator*=(foo&); ... The first operator: ... $ c++filt _ZN3foomlERS_ foo::operator*(foo&) ... matches address 0x410250 which is defined here in the CU in the exec: ... <1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram) <10f2> DW_AT_specification: <alt 0x93> <10f6> DW_AT_decl_line : 72 <10f7> DW_AT_decl_column : 7 <10f7> DW_AT_object_pointer: <0x1106> <10f9> DW_AT_low_pc : 0x410250 <1101> DW_AT_high_pc : 32 <1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <1104> DW_AT_call_all_calls: 1 ... and declared here in the PU in the .dwz file: ... <2><93>: Abbrev Number: 20 (DW_TAG_subprogram) <94> DW_AT_external : 1 <94> DW_AT_name : operator* <98> DW_AT_decl_file : 2 <98> DW_AT_decl_line : 10 <99> DW_AT_decl_column : 9 <9a> DW_AT_linkage_name: _ZN3foomlERS_ <9e> DW_AT_accessibility: 1 (public) <9e> DW_AT_declaration : 1 <9e> DW_AT_object_pointer: <0xa2> ... When creating a new symbol for the operator, the DW_AT_decl_file attribute is looked up, and found to be 2. The 2 is supposed to be mapped using the PU, which has this file name table: ... The File Name Table (offset 0x78, lines 3, columns 2): Entry Dir Name 0 0 <dwz> 1 1 stddef.h 2 2 cplusfuncs.cc ... Instead, it's mapped using the CU, which has this file name table: ... The File Name Table (offset 0x34, lines 3, columns 2): Entry Dir Name 0 1 cplusfuncs.cc 1 1 cplusfuncs.cc 2 2 stddef.h ... This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where the same problem happens for two CUs. Fix this by using the correct file name table. Add a dwarf assembly test-case for PR25771. Tested on aarch64-linux. Reviewed-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814
* [gdb/symtab] Skip local variables in cooked indexTom de Vries2024-10-192-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider test-case gdb.dwarf2/local-var.exp. The corresponding source contains a function with a local variable: ... program test logical :: local_var local_var = .TRUE. end ... Currently, the local variable shows up in the cooked index: ... [2] ((cooked_index_entry *) 0xfffec40063b0) name: local_var canonical: local_var qualified: local_var DWARF tag: DW_TAG_variable flags: 0x2 [IS_STATIC] DIE offset: 0xa3 parent: ((cooked_index_entry *) 0xfffec4006380) [test] ... making the cooked index larger than necessary. Fix this by skipping it in cooked_indexer::index_dies. Tested on aarch64-linux. PR symtab/32276 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32276
* [gdb/testsuite] Fix gdb.dwarf2/enum-type-c++.exp with clangTom de Vries2024-10-101-15/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get: ... FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1 FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2 ... The problem is that the debug info produced by clang does not contain any references to enumerators val1 and val2, or the corresponding enumeration types. Instead, the variables u1 and u2 are considered to be simply of type int: ... <1><fb>: Abbrev Number: 2 (DW_TAG_variable) <fc> DW_AT_name : u1 <fd> DW_AT_type : <0x106> <101> DW_AT_external : 1 <103> DW_AT_location : (DW_OP_addrx <0>) <1><106>: Abbrev Number: 3 (DW_TAG_base_type) <107> DW_AT_name : int <108> DW_AT_encoding : 5 (signed) <109> DW_AT_byte_size : 4 <1><10a>: Abbrev Number: 2 (DW_TAG_variable) <10b> DW_AT_name : u2 <10c> DW_AT_type : <0x106> <110> DW_AT_external : 1 <112> DW_AT_location : (DW_OP_addrx <0x1>) ... Fix this by checking whether val1 and val2 are present in the cooked index before checking whether they have the correct parent. This cannot be expressed efficiently with gdb_test_lines, so factor out gdb_get_lines and use that instead. The test-case still calls "maint print objfiles" twice, but the first time is for have_index. We should probably use a gdb_caching_proc for this. Tested on aarch64-linux. Reported-By: Guinevere Larsen <guinevere@redhat.com> Reviewed-By: Keith Seitz <keiths@redhat.com> Tested-By: Guinevere Larsen <guinevere@redhat.com>
* [gdb/testsuite] Fix some gdb.dwarf2 test-cases for check-read1Tom de Vries2024-10-105-6/+15
| | | | | | | | | I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output. Tested on x86_64-linux.
* [gdb/symtab] Fix parent of enumeratorTom de Vries2024-10-081-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in test-case gdb.dwarf2/enum-type.exp, for val1 we get an entry without parent: ... [27] ((cooked_index_entry *) 0x7fbbb4002ef0) name: val1 canonical: val1 qualified: val1 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0x124 parent: ((cooked_index_entry *) 0) ... This happens here in cooked_indexer::index_dies: ... info_ptr = recurse (reader, info_ptr, is_enum_class ? this_entry : parent_entry, fully); ... when we're passing down a nullptr parent_entry, while the parent of this_entry is deferred. Fix this in cooked_indexer::index_dies by passing down a deffered parent instead, such that we get: ... [27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M name: val1^M canonical: val1^M qualified: ns::val1^M DWARF tag: DW_TAG_enumerator^M flags: 0x0 []^M DIE offset: 0x124^M parent: ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M ... Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
* [gdb/contrib] Add more separators in spellcheck.shTom de Vries2024-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | | Add two more separators in spellcheck.sh: colon and comma. Doing so triggers the "inbetween->between" rule, which gives an incorrect result. Override this with "inbetween->between, in between, in-between" [1], in a new file gdb/contrib/common-misspellings.txt. Fix the following common misspellings: ... everytime -> every time sucess -> success thru -> through transfered -> transferred inbetween -> between, in between, in-between ... Verified with spellcheck.sh. Tested on x86_64-linux. [1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/
* [gdb] Fix common misspellingsTom de Vries2024-10-064-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following common misspellings: ... accidently -> accidentally additonal -> additional addresing -> addressing adress -> address agaisnt -> against albiet -> albeit arbitary -> arbitrary artifical -> artificial auxillary -> auxiliary auxilliary -> auxiliary bcak -> back begining -> beginning cannonical -> canonical compatiblity -> compatibility completetion -> completion diferent -> different emited -> emitted emiting -> emitting emmitted -> emitted everytime -> every time excercise -> exercise existance -> existence fucntion -> function funtion -> function guarentee -> guarantee htis -> this immediatly -> immediately layed -> laid noone -> no one occurances -> occurrences occured -> occurred originaly -> originally preceeded -> preceded preceeds -> precedes propogate -> propagate publically -> publicly refering -> referring substract -> subtract substracting -> subtracting substraction -> subtraction taht -> that targetting -> targeting teh -> the thier -> their thru -> through transfered -> transferred transfering -> transferring upto -> up to vincinity -> vicinity whcih -> which whereever -> wherever wierd -> weird withing -> within writen -> written wtih -> with doesnt -> doesn't ... Tested on x86_64-linux.
* [gdb/symtab] Fix segfault on invalid debug infoTom de Vries2024-09-241-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While looking at PR symtab/31478 (a problem in the cooked indexer with invalid dwarf) it occurred to me that I could trigger a similar problem using: ... Compilation Unit @ offset 0xb2: Length: 0x1f (32-bit) Version: 4 Abbrev Offset: 0x6c Pointer Size: 8 <0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit) <be> DW_AT_language : 2 (non-ANSI C) <1><bf>: Abbrev Number: 2 (DW_TAG_subprogram) <c0> DW_AT_low_pc : 0x4004a7 <c8> DW_AT_high_pc : 0x4004b2 <d0> DW_AT_specification: <0xd5> <1><d4>: Abbrev Number: 0 Compilation Unit @ offset 0xd5: Length: 0x7 (32-bit) Version: 4 Abbrev Offset: 0x7f Pointer Size: 8 ... and indeed I get: ... $ gdb -q -batch outputs/gdb.dwarf2/dw2-inter-cu-error-2/dw2-inter-cu-error-2 Fatal signal: Segmentation fault ... The problem is that we're calling prepare_one_comp_unit with cu == nullptr and comp_unit_die == nullptr here in cooked_indexer::ensure_cu_exists: ... cutu_reader new_reader (per_cu, per_objfile, nullptr, nullptr, false, m_index_storage->get_abbrev_cache ()); prepare_one_comp_unit (new_reader.cu, new_reader.comp_unit_die, language_minimal); ... Fix this by bailing out for various types of dummy CUs: ... if (new_reader.dummy_p || new_reader.comp_unit_die == nullptr || !new_reader.comp_unit_die->has_children) return nullptr; ... Also make sure in scan_attributes that this triggers a dwarf error: ... $ gdb -q -batch dw2-inter-cu-error-2 DWARF Error: cannot follow reference to DIE at 0xd5 \ [in module dw2-inter-cu-error-2] ... With target board readnow, the test-case triggers an assertion failure in follow_die_offset, so fix this by throwing the same dwarf error. While we're at it, make the other check for dummy CUs in cooked_indexer::ensure_cu_exists more robust by adding an intermediate test for comp_unit_die: ... - if (result->dummy_p || !result->comp_unit_die->has_children) + if (result->dummy_p || result->comp_unit_die == nullptr + || !result->comp_unit_die->has_children) return nullptr; ... Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
* [gdb/testsuite] Add gdb.dwarf2/dwz-unused-pu.expTom de Vries2024-09-241-0/+75
| | | | | | | | | | | | | Add a new test-case gdb.dwarf2/dwz-unused-pu.exp that checks that a symbol from an unused PU is not accessible. Passes with the relevant target boards: - unix (using the cooked index), - readnow (using no index at all), - cc-with-gdb-index (using .gdb_index), and - cc-with-debug-names (using .debug_names). Tested on x86_64-linux.
* [gdb/testsuite] Drop -readnow in three gdb.dwarf2 test-casesTom de Vries2024-09-213-32/+4
| | | | | | | | | | | | | | | | | | | | | When running the testsuite in an enviroment simulating a stressed system, I ran into timeouts in three test-cases in gdb.dwarf2: - gdb.dwarf2/count.exp, - gdb.dwarf2/implptrconst.exp, and - gdb.dwarf2/implptrpiece.exp. In all three cases, -readnow is used which results in symtabs being expanded for the executable, /lib64/libc.so.6 and /lib64/ld-linux-x86-64.so.2. We could address this by limiting the scope of -readnow to the executable, but after reviewing the test-cases there doesn't seem to be a clear reason to use -readnow. Fix this by dropping the -readnow. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
* [gdb/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF ↵Tom de Vries2024-09-142-2/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scanner" After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds this debug info: ... <1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type) <120> DW_AT_specification: <0x130> <2><124>: Abbrev Number: 4 (DW_TAG_enumerator) <125> DW_AT_name : val1 <12a> DW_AT_const_value : 1 <2><12b>: Abbrev Number: 0 <1><12c>: Abbrev Number: 5 (DW_TAG_namespace) <12d> DW_AT_name : ns <2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type) <131> DW_AT_name : e <133> DW_AT_type : <0x118> <137> DW_AT_declaration : 1 ... I run into an assertion failure: ... (gdb) file enum-type^M Reading symbols from enum-type...^M cooked-index.h:214: internal-error: get_parent: \ Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M ... This was reported in PR32160 comment 1. This is a regression since commit 4e417d7bb1c ("Change handling of DW_TAG_enumeration_type in DWARF scanner"). Fix this by reverting the commit. [ Also drop the kfails for PR31900 and PR32158, which are regressions by that same commit. ] That allows us to look at the output of "maint print objfiles", and for val1 we get an entry without parent: ... [27] ((cooked_index_entry *) 0x7fbbb4002ef0) name: val1 canonical: val1 qualified: val1 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0x124 parent: ((cooked_index_entry *) 0) ... which is incorrect, as noted in that same comment, but an improvement over the assertion failure, and I don't think that ever worked. This is to be addressed in a follow-up patch. Reverting the commit begs the question: what was it trying to fix in the first place, and do we need a different fix? I've investigated this and filed PR32160 to track this. My guess is that the commit was based on a misunderstand of what we track in cooked_indexer::m_die_range_map. Each DIE has two types of parent DIEs: - a DIE that is the parent as indicated by the tree structure in which DIEs occur, and - a DIE that represent the parent scope. In most cases, these two are the same, but some times they're not. The debug info above demonstrates such a case. The DIE at 0x11f: - has a tree-parent: the DIE representing the CU, and - has a scope-parent: DIE 0x12c representing namespace ns. In cooked_indexer::m_die_range_map, we track scope-parents, and the commit tried to add a tree-parent instead. So, I don't think we need a different fix, and propose we backport the reversal for gdb 15.2. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160
* [gdb/testsuite] Add regression test for PR32158Tom de Vries2024-09-142-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider test-case: ... namespace ns { enum class ec { val2 = 2 }; } int main () { return (int)ns::ec::val2; } ... compiled with debug info: ... $ g++ test.c -g ... When looking at the cooked index entry for val2 using "maint print objfiles", we get: ... [7] ((cooked_index_entry *) 0x7f8ecc002ef0) name: val2 canonical: val2 qualified: ns::val2 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0xe9 parent: ((cooked_index_entry *) 0x7f8ecc002e90) [ns] ... which is wrong, there is no source level entity ns::val2. This is PR symtab/32158. This is a regression since commit 4e417d7bb1c ("Change handling of DW_TAG_enumeration_type in DWARF scanner"). Reverting the commit on current trunk fixes the problem, and gets us instead: ... [7] ((cooked_index_entry *) 0x7fba70002ef0) name: val2 canonical: val2 qualified: ns::ec::val2 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0xe9 parent: ((cooked_index_entry *) 0x7fba70002ec0) [ec] ... Add a regression test for this PR in test-case gdb.dwarf2/enum-type-c++.exp. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
* [gdb/testsuite] Add gdb.dwarf2/enum-type-c++.exp, regression test for PR31900.Tom de Vries2024-09-142-0/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following test-case: ... $ cat a.h namespace ns { class A { public: enum { val1 = 1 }; }; } $ cat main.c ns::A a; int main (void) { return 0; } $ cat val1.c int u1 = ns::A::val1; ... compiled with debug info: ... $ g++ main.c val1.c -g ... When trying to print ns::A::val with current trunk and gdb 15.1 we get: ... $ gdb -q -batch a.out -ex "print ns::A::val1" There is no field named val1 ... This PR c++/31900. With gdb 14.2 we get the expected: ... $ gdb -q -batch a.out -ex "print ns::A::val1" $1 = ns::A::val1 ... This is a regression since commit 4e417d7bb1c ("Change handling of DW_TAG_enumeration_type in DWARF scanner"). Reverting the commit on current trunk fixes the problem. So how does this problem happen? First, let's consider the current trunk, with the commit reverted. Gdb looks for the entry ns::A::val1, and find this entry: ... [29] ((cooked_index_entry *) 0x7f7830002ef0) name: val1 canonical: val1 qualified: ns::A::val1 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0x15a parent: ((cooked_index_entry *) 0x7f7830002ec0) [A] ... and expands the corresponding CU val1.c containing this debug info: ... <2><14a>: Abbrev Number: 3 (DW_TAG_class_type) <14b> DW_AT_name : A <14d> DW_AT_byte_size : 1 <3><150>: Abbrev Number: 4 (DW_TAG_enumeration_type) <151> DW_AT_encoding : 7 (unsigned) <152> DW_AT_byte_size : 4 <153> DW_AT_type : <0x163> <159> DW_AT_accessibility: 1 (public) <4><15a>: Abbrev Number: 5 (DW_TAG_enumerator) <15b> DW_AT_name : val1 <15f> DW_AT_const_value : 1 <4><160>: Abbrev Number: 0 <3><161>: Abbrev Number: 0 <2><162>: Abbrev Number: 0 ... after which it finds ns::A::val1 in the expanded symtabs. Now let's consider the current trunk as is (so, with the commit present). Gdb looks for the entry ns::A::val1, but doesn't find it because the val1 entry is missing its parent: ... [29] ((cooked_index_entry *) 0x7f5240002ef0) name: val1 canonical: val1 qualified: val1 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0x15a parent: ((cooked_index_entry *) 0) ... Then gdb looks for the entry ns::A, and finds this entry: ... [3] ((cooked_index_entry *) 0x7f5248002ec0) name: A canonical: A qualified: ns::A DWARF tag: DW_TAG_class_type flags: 0x0 [] DIE offset: 0xdd parent: ((cooked_index_entry *) 0x7f5248002e90) [ns] ... which corresponds to this debug info, which doesn't contain val1 due to -fno-eliminate-unused-debug-types: ... <2><dd>: Abbrev Number: 3 (DW_TAG_class_type) <de> DW_AT_name : A <e0> DW_AT_byte_size : 1 <2><e3>: Abbrev Number: 0 ... Gdb expands the corresponding CU main.c, after which it doesn't find ns::A::val1 in the expanded symtabs. The root cause of the problem is the missing parent on the val1 cooked_index_entry, but this only becomes user-visible through the elaborate scenario above. Add a test-case gdb.dwarf2/enum-type-c++.exp that contains a regression test for this problem that doesn't rely on expansion state or -feliminate-unused-debug-types, but simply tests for the root cause by grepping for ns::A::val1 in the output of "maint print objfile". Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
* [gdb/testsuite] Simplify gdb.dwarf2/forward-spec.expTom de Vries2024-09-111-28/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Test-case gdb.dwarf2/forward-spec.exp contains a non-trivial gdb_test_multiple to parse this cooked_index_entry: ... [5] ((cooked_index_entry *) 0x7f01f0004040)^M name: v^M canonical: v^M qualified: ns::v^M DWARF tag: DW_TAG_variable^M flags: 0x2 [IS_STATIC]^M DIE offset: 0xcb^M parent: ((cooked_index_entry *) 0x7f01f00040a0) [ns]^M ... which allows us to verify that the entry has a parent. After commit 8f258a6c979 ("[gdb/symtab] Dump qualified name of cooked_index_entry") that's no longer necessary. Simplify this by checking for ns::v instead. While we're at it, also fix the test-case for target boards readnow, cc-with-gdb-index and cc-with-debug-names. Tested on x86_64-linux.
* [gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp on arm-linuxTom de Vries2024-09-043-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With test-case gdb.dwarf2/dw2-lines.exp on arm-linux, I run into: ... (gdb) break bar_label^M Breakpoint 2 at 0x4004f6: file dw2-lines.c, line 29.^M (gdb) continue^M Continuing.^M ^M Breakpoint 2, bar () at dw2-lines.c:29^M 29 foo (2);^M (gdb) PASS: $exp: cv=2: cdw=32: lv=2: ldw=32: continue to breakpoint: foo \(1\) ... The pass is incorrect because the continue lands at line 29 with "foo (2)" instead of line line 27 with "foo (1)". A minimal version is: ... $ gdb -q -batch dw2-lines.cv-2-cdw-32-lv-2-ldw-32 -ex "b bar_label" Breakpoint 1 at 0x4f6: file dw2-lines.c, line 29. ... where: ... 000004ec <bar>: 4ec: b580 push {r7, lr} 4ee: af00 add r7, sp, #0 000004f0 <bar_label>: 4f0: 2001 movs r0, #1 4f2: f7ff fff1 bl 4d8 <foo> 000004f6 <bar_label_2>: 4f6: 2002 movs r0, #2 4f8: f7ff ffee bl 4d8 <foo> ... So, how does this happen? In short: - skip_prologue_sal calls arm_skip_prologue with pc == 0x4ec, - thumb_analyze_prologue returns 0x4f2 (overshooting by 1 insn, PR tdep/31981), and - skip_prologue_sal decides that we're mid-line, and updates to 0x4f6. However, this is a test-case about .debug_line info, so why didn't arm_skip_prologue use the line info to skip the prologue? The answer is that the line info starts at bar_label, not at bar. Fixing that allows us to work around PR tdep/31981. Likewise in gdb.dwarf2/dw2-line-number-zero.exp. Instead, add a new test-case gdb.arch/skip-prologue.exp that is dedicated to checking quality of architecture-specific prologue analysis, without being written in an architecture-specific way. If fails on arm-linux for both marm and mthumb: ... FAIL: gdb.arch/skip-prologue.exp: f2: $bp_addr == $prologue_end_addr (skipped too much) FAIL: gdb.arch/skip-prologue.exp: f4: $bp_addr == $prologue_end_addr (skipped too much) ... and passes for: - x86_64-linux for {m64,m32}x{-fno-PIE/-no-pie,-fPIE/-pie} - aarch64-linux. Tested on arm-linux.
* [gdb/testsuite] Fix regexp in gdb.dwarf2/dw2-inter-cu-error.expTom de Vries2024-08-271-1/+1
| | | | | | | | | | In commit b5070480d74 ("[gdb/symtab] Change DWARF_ERROR from Dwarf Error to DWARF Error") I changed the dwarf error prefix, but failed to update test-case gdb.dwarf2/dw2-inter-cu-error.exp. Fix this by updating the corresponding regexp in the test-case. Tested on x86_64-linux.
* [gdb/symtab] Change DWARF_ERROR from Dwarf Error to DWARF ErrorTom de Vries2024-08-275-6/+6
| | | | | | | | | | | | | | | | | | It was suggested here [1] that the canonical prefix for dwarf errors should not be "Dwarf Error: ", given that the canonical spelling is DWARF instead of Dwarf. Fix this by using "DWARF Error: " instead. Given the use of DWARF_ERROR_PREFIX, that needs to be changed only in a single location. Tested on x86_64-linux. Suggested-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com> [1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html
* gdb/dwarf2: Check for null abbrev_info ptrAaron Merey2024-08-231-0/+51
| | | | | | | | | | | | | | | | | | | | A corrupt debuginfo file can result in a null abbrev_info pointer being passed to cooked_indexer::scan_attributes. This pointer is set to nullptr by peek_die_abbrev when an abbrev of 0 is found. There is no check for whether the abbrev pointer is null and SIGSEGV occurs when attempting to dereference the pointer. An abbrev of 0 normally indicates that the corresponding DIE is a null entry, but scan_attributes expects a non-null DIE. Fix this by throwing an error in cooked_indexer::scan_attributes when peek_die_abbrev returns a nullptr in order to avoid scan_attributes calling itself with a null abbrev. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31478 Co-authored-by: Tom de Vries <tdevries@suse.de> Approved-By: Tom Tromey <tom@tromey.com>
* [gdb/symtab] Return correct reader for top-level CU in ↵Tom de Vries2024-08-221-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cooked_indexer::ensure_cu_exists With the test-case included in this patch, we run into: ... $ gdb -q -batch $exec Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \ [in module $exec] ... The debug info consists of two CUs: ... Compilation Unit @ offset 0xb2: Length: 0x25 (32-bit) Version: 4 Abbrev Offset: 0x6c Pointer Size: 8 <0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit) <be> DW_AT_language : 2 (non-ANSI C) <1><bf>: Abbrev Number: 2 (DW_TAG_subprogram) <c0> DW_AT_low_pc : 0x4004a7 <c8> DW_AT_high_pc : 0x4004b2 <d0> DW_AT_specification: <0xe8> <1><d4>: Abbrev Number: 3 (DW_TAG_subprogram) <d5> DW_AT_name : main <1><da>: Abbrev Number: 0 Compilation Unit @ offset 0xdb: Length: 0xf (32-bit) Version: 4 Abbrev Offset: 0x86 Pointer Size: 8 <0><e6>: Abbrev Number: 1 (DW_TAG_compile_unit) <e7> DW_AT_language : 2 (non-ANSI C) <1><e8>: Abbrev Number: 2 (DW_TAG_subprogram) <e9> DW_AT_specification: <0xd4> <1><ed>: Abbrev Number: 0 ... where: - DIE 0xbf in CU@0xb2 contains an inter-CU reference to - DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to - DIE 0xd4 back in CU@0xb2. The dwarf error is caused by this bit of code in cooked_indexer::ensure_cu_exists: ... if (per_cu == m_per_cu) return reader; ... The dwarf error happens as follows: - a cutu_reader A is created for CU@0xb2 - using cutu_reader A, the cooked index reader starts indexing dies, with m_per_cu set to CU@0xb2 - while indexing it scans the attributes of DIE 0xbf and encounters the inter-CU reference to DIE 0xe8 - it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for CU@0xdb and returns it - using cutu_reader B, it continues scanning attributes of DIE 0xe8 and encounters the inter-CU reference to DIE 0xd4 - it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered and cutu_reader B is returned - using cutu_reader B, it continues scanning attributes of DIE 0xd4 - this goes wrong because: - the attributes of the DIE are encoded using the abbreviation table at offset 0x6c, while - the decoding is done using cutu_reader B which uses the abbreviation table at offset 0x86. Fix this by removing the problematic if clause. Since cutu_reader A is not preserved in m_index_storage, cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate cutu_reader C for CU@0xb2. Fix this in process_psymtab_comp_unit by preserving the cutu_reader A as well in m_index_storage. Tested on x86_64-linux and aarch64-linux. PR symtab/32081 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32081 Approved-By: Tom Tromey <tom@tromey.com> Reported-By: Andreas Schwab <schwab@linux-m68k.org>
* [gdb/testsuite] Fix gdb.dwarf2/dw2-fixed-point.exp on arm-linuxTom de Vries2024-08-161-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into: ... (gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada print pck.fp1_var^M $1 = 0.3125^M (gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var ... The problem is that the thumb prologue analyzer overshoot, setting the breakpoint for main after line 49: ... 46 int 47 main (void) 48 { 49 pck__fp1_var++; ... and consequently we see the value of pck.fp1_var after line 49 instead of before line 49. This is PR tdep/31981. Work around this by removing line 49 and all similar subsequent lines, which turn out to be dead code. Approved-By: Luis Machado <luis.machado@arm.com> Tested on arm-linux.
* [gdb/testsuite] Fix trailing-text-in-parentheses duplicatesTom de Vries2024-07-311-3/+3
| | | | | | Fix all trailing-text-in-parentheses duplicates exposed by previous patch. Tested on x86_64-linux and aarch64-linux.
* [gdb/symtab] Emit malformed macro definition complaint onceTom de Vries2024-07-301-0/+198
| | | | | | | | | | | | | | | | | | | Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the .debug_macro section. For one malformed macro definition, I get two identical complaints: ... During symbol reading: macro debug info contains a malformed macro definition:^M `M1_11_MALFORMED(ARG'^M During symbol reading: macro debug info contains a malformed macro definition:^M `M1_11_MALFORMED(ARG'^M ... Fix this by bailing out after the first one. Tested on aarch64-linux. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
* gdb/testsuite: fix build-id compile option when used with clangAndrew Burgess2024-07-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was pointed out in this message: https://inbox.sourceware.org/gdb-patches/5d7a514b-5dad-446f-a021-444ea88ecf07@redhat.com That the test gdb.base/build-id-seqno.exp I added recently was FAILing when using Clang as the compiler. The problem was that I had failed to add 'build-id' as a compile option in the call to build_executable within the test script. For GCC this is fine as build-ids are included by default. For Clang though this meant the build-id was not included and the test would fail. So I added build-id to the compiler options.... and the test still didn't pass! Now the test fails to compile and I see this error from the compiler: gdb compile failed, clang-15: warning: -Wl,--build-id: 'linker' \ input unused [-Wunused-command-line-argument] It turns out that the build-id compile option causes our gdb.exp to add the '-Wl,--build-id' option into the compiler flags, which means its used when building the object file AND during the final link. However this option is unnecessary when creating the object file and Clang warns about this, which causes the build to fail. The solution is to change gdb.exp, instead of adding the build-id flags like this: lappend new_options "additional_flags=-Wl,--build-id" we should instead add them like: lappend new_options "ldflags=-Wl,--build-id" Now the flag is only appended during the link phase and Clang is happy. The gdb.base/build-id-seqno.exp test now passes with Clang. The same problem (adding to additional_flags instead of ldflags) exists for the no-build-id compile option, so I've fixed that too. While investigating this I also spotted two test scripts, gdb.base/index-cache.exp and gdb.dwarf2/per-bfd-sharing.exp which were setting ldflag directly rather than using the build-id compile option so I've updated these two tests to use the compile option which I think is neater. I've checked that all these tests still pass with both GCC and Clang. There should be no changes in what is actually tested after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
* [gdb/testsuite] Handle address class annotation for s390x in some test-casesTom de Vries2024-07-243-7/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | On s390x-linux, I ran into: ... (gdb) ptype crash^M type = class crash {^M ^M public:^M crash(int (class {...}::*)(class {...} * const @mode32));^M }^M (gdb) FAIL: gdb.dwarf2/dw2-anon-mptr.exp: ptype crash ... The problem is that the test-case doesn't expect the address class annotation @mode32. The test-case uses a .S file, with the address size hard-coded to 4 bytes, and that's something that is annotated with @mode32 on s390x (which uses 8 byte addresses). Fix this by allowing the annotation in the regexp. Likewise in two other test-cases. Tested on s390-linux and x86_64-linux.
* gdb: use alternative for demangled name for non-demangeable linkage namesSchimpe, Christina2024-06-252-0/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case a DIE contains a linkage name which cannot be demangled and a source language name (DW_AT_NAME) exists then we want to display this name instead of the non-demangeable linkage name. dwarf2_physname returns the linkage name in case the linkage name cannot be demangled. Before this patch we always set the returned physname as demangled name. This patch changes this by comparing the value of physname with the linkage name. Now after this change in case it is equals to the linkage name and if DW_AT_NAME exists then this is set as the demangled name otherwise like before still linkage name is used. For the reproducer, using the test source file added in this change: "gdb/testsuite/gdb.dwarf2/dw2-wrong-mangled-name.c" Here is an example of the DWARF where wrong linkage name is emitted by the compiler for the "func_demangled_test" function: subprogram { {MACRO_AT_range {func_demangled_test}} {linkage_name "_FUNC_WRONG_MANGLED__"} {name "func_demangled_test"} {external 1 flag} } subprogram { {MACRO_AT_range {main}} {external 1 flag} {name main} {main_subprogram 1 flag} } Before this change for a function having both DIEs DW_AT_name and DW_AT_LINKAGENAME but with the wrong linkage name info, the backtrace command shows following: (gdb) b func_demangled_test (gdb) r Breakpoint 1, 0x0000555555555131 in _FUNC_WRONG_MANGLED__ () (gdb) backtrace \#0 0x0000555555555131 in _FUNC_WRONG_MANGLED__ () \#1 0x000055555555514a in main () After the change now GDB shows the name emitted by DW_AT_NAME: (gdb) b func_demangled_test (gdb) r Breakpoint 1, 0x0000555555555131 in func_demangled_test () (gdb) backtrace \#0 0x0000555555555131 in func_demangled_test () \#1 0x000055555555514a in main () A new test is added to verify this change. Approved-By: Tom Tromey <tom@tromey.com>
* [gdb/symtab] Fix target type of complex long double on armTom de Vries2024-06-191-0/+244
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running test-case gdb.base/complex-parts.exp on arm-linux, I get: ... (gdb) p $_cimag (z3)^M $6 = 6.5^M (gdb) PASS: gdb.base/complex-parts.exp: long double imaginary: p $_cimag (z3) ptype $^M type = double^M (gdb) FAIL: gdb.base/complex-parts.exp: long double imaginary: ptype $ ... Given that z3 is a complex long double, the test-case expects the type of the imaginary part of z3 to be long double, but it's double instead. This is due to the fact that the dwarf info doesn't specify an explicit target type: ... <5b> DW_AT_name : z3 <60> DW_AT_type : <0xa4> ... <1><a4>: Abbrev Number: 2 (DW_TAG_base_type) <a5> DW_AT_byte_size : 16 <a6> DW_AT_encoding : 3 (complex float) <a7> DW_AT_name : complex long double ... and consequently we're guessing in dwarf2_init_complex_target_type based on the size: ... case 64: tt = builtin_type (gdbarch)->builtin_double; break; case 96: /* The x86-32 ABI specifies 96-bit long double. */ case 128: tt = builtin_type (gdbarch)->builtin_long_double; break; ... For arm-linux, complex long double is 16 bytes, so the target type is assumed to be 8 bytes, which is handled by the "case 64", which gets us double instead of long double. Fix this by searching for "long" in the name_hint parameter, and using long double instead. Note that base types in dwarf are not allowed to contain references to other types, and the complex types are base types, so the missing explicit target type is standard-conformant. A gcc PR was filed to add this as a dwarf extension ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 ). Tested on arm-linux.
* [gdb/testsuite] Fix gdb.dwarf2/shortpiece.exp on s390xTom de Vries2024-06-191-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On s390x-linux, I run into: ... (gdb) p (short []) s1^M $3 = {0, 1, 0, <optimized out>}^M (gdb) FAIL: gdb.dwarf2/shortpiece.exp: p (short []) s1 ... while this is expected: ... (gdb) p (short []) s1^M $3 = {1, 0, 0, <optimized out>}^M (gdb) PASS: gdb.dwarf2/shortpiece.exp: p (short []) s1 ... The type of s1 is: ... (gdb) ptype s1 type = struct S { myint a; myushort b; } ... so the difference is due the fact that viewing an int as two shorts gives different results depending on the endianness. Fix this by allowing both results. Tested on x86_64-linux and s390x-linux. Approved-By: Tom Tromey <tom@tromey.com>
* [gdb/testsuite] Don't use set auto-solib-add offTom de Vries2024-06-101-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In test-case gdb.mi/mi-var-child-f.exp, we have: ... mi_gdb_test "-gdb-set auto-solib-add off" "\\^done" mi_runto prog_array mi_gdb_test "nosharedlibrary" ".*\\^done" ... This was added to avoid a name clash between the array variable as defined in gdb.mi/array.f90 and debug info in shared libraries, and used in other places in the testsuite. The same workaround is also used to ignore symbols from shared libraries when excercising for instance a command that prints all symbols. However, this approach can cause problems for targets like arm that require symbol info for some libraries like ld.so and libc to fully function. While absense of debug info for shared libraries should be handled gracefully (which does need fixing, see PR31817), failure to do so should not result in failures in unrelated test-cases. Fix this by removing "set auto-solib-add off". This ensures that we don't run into PR31817, while the presence of nosharedlibrary still ensures that in the rest of the test-case we're not bothered by shared library symbols. Likewise in other test-cases. Approved-by: Kevin Buettner <kevinb@redhat.com> Tested on arm-linux.
* [gdb/testsuite] Add missing terminator in Dwarf::_macro_unitTom de Vries2024-05-161-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When printing complaints with one of the execs from test-case gdb.dwarf2/macro-source-path.exp, we run into: ... $ gdb -q -batch \ -iex "set complaints 100" \ macro-source-path-clang14-dw4-absolute-cwd-32 \ -ex "p main" During symbol reading: debug info runs off end of .debug_macro section \ [in module macro-source-path-clang14-dw4-absolute-cwd-32] $1 = {int ()} 0x4004b7 <main> ... and readelf complains more specifically: ... Contents of the .debug_macro section: Offset: 0 Version: 5 Offset size: 4 Offset into .debug_line: 0xe3 DW_MACRO_define - lineno : 0 macro : ONE 1 DW_MACRO_define_strp - lineno : 0 macro : THREE 3 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c DW_MACRO_define - lineno : 1 macro : TWO 2 DW_MACRO_end_file readelf: Error: .debug_macro section not zero terminated ... Fix this by adding the missing terminator in Dwarf::_macro_unit. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
* [gdb/testsuite] Generate DW_MACRO_define_strp in dwarf assemblyTom de Vries2024-05-161-0/+2
| | | | | | | | | Add support for DW_MACRO_define_strp in dwarf assembly, and use it in test-case gdb.dwarf2/macro-source-path.exp. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
* [gdb/testsuite] Use save_vars to restore GDBFLAGSTom de Vries2024-05-038-37/+34
| | | | | | | | | | | | | | | | | | | | There's a pattern of using: ... set saved_gdbflags $GDBFLAGS set GDBFLAGS "$GDBFLAGS ..." <do something with GDBFLAGS> set GDBFLAGS $saved_gdbflags ... Simplify this by using save_vars: ... save_vars { GDBFLAGS } { set GDBFLAGS "$GDBFLAGS ..." <do something with GDBFLAGS> } ... Tested on x86_64-linux.
* [gdb/symtab] Work around PR gas/29517, dwarf2 caseTom de Vries2024-05-023-2/+31
| | | | | | | | | | | | | | | | | | | | In commit 1d45d90934b ("[gdb/symtab] Work around PR gas/29517") we added a workaround for PR gas/29517. The problem is present in gas version 2.39, and fixed in 2.40, so the workaround is only active for gas version == 2.39. However, the problem in gas is only fixed for dwarf version >= 3, which supports DW_TAG_unspecified_type. Fix this by also activating the workaround for dwarf version == 2. Tested on x86_64-linux. Approved-by: Kevin Buettner <kevinb@redhat.com> PR symtab/31689 https://sourceware.org/bugzilla/show_bug.cgi?id=31689
* [gdb/testsuite] Fix stray file in gdb.dwarf2/gdb-index-nodebug.expTom de Vries2024-05-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | After running test-case gdb.dwarf2/gdb-index-nodebug.exp I have: ... $ ls build/gdb/testsuite cache config.status gdb.log lib outputs site.exp config.log gdb-index-nodebug.gdb-index gdb.sum Makefile site.bak temp ... The file gdb-index-nodebug.gdb-index doesn't belong there. It happens to be there because we do: ... set index_file ${testfile}.gdb-index set cmd "save gdb-index [file dirname ${index_file}]" ... which results in: ... (gdb) save gdb-index . ... The intention was possibly to use $binfile instead of $testfile, but using that wouldn't work for remote host. Fix this by using host_standard_output_file. Tested on x86_64-linux.
* Fix end_sequence addresses for dw2-lines.expCarl Love2024-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch: From f0d556d14b1d1c3f8e2f9c13b08adca22e1b8c9c Mon Sep 17 00:00:00 2001 From: Tom de Vries <tdevries@suse.de> Date: Wed, 17 Apr 2024 12:55:00 +0200 Subject: [PATCH] [gdb/testsuite] Fix end_sequence addresses I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: ... 00000000004102c4 <end_of_sequence>: 4102c4: 52800000 mov w0, #0x0 // #0 4102c8: 9100c3ff add sp, sp, #0x30 4102cc: d65f03c0 ret ... is not described by the line table: ... <snip> The regression failure on PowerPC is due to the change in file dw2-lines.exp, - DW_LNE_set_address bar_label_5 + DW_LNE_set_address "$main_start + $main_len" The label bar_label_5 is in function bar, not function main. The new set address should have been $bar_start + $bar_len.
* Handle two-linetable function in find_epilogue_using_linetableBernd Edlinger2024-04-244-156/+272
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following test-case: ... $ cat hello.c int main() { printf("hello "); #include "world.inc" $ cat world.inc printf("world\n"); return 0; } $ gcc -g hello.c ... The line table for the compilation unit, consisting just of function main, is translated into these two gdb line tables, one for hello.c and one for world.inc: ... compunit_symtab: hello.c symtab: hello.c INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN 0 3 0x400557 0x400557 Y 1 4 0x40055b 0x40055b Y 2 END 0x40056a 0x40056a Y compunit_symtab: hello.c symtab: world.inc INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN 0 1 0x40056a 0x40056a Y 1 2 0x400574 0x400574 Y 2 3 0x400579 0x400579 Y 3 END 0x40057b 0x40057b Y ... The epilogue of main starts at 0x400579: ... 400579: 5d pop %rbp 40057a: c3 ret ... Now, say we have an epilogue_begin marker in the line table at 0x400579. We won't find it using find_epilogue_using_linetable, because it does: ... const struct symtab_and_line sal = find_pc_line (start_pc, 0); ... which gets us the line table for hello.c. Fix this by using "find_pc_line (end_pc - 1, 0)" instead. Tested on x86_64-linux. Co-Authored-By: Tom de Vries <tdevries@suse.de> PR symtab/31622 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31622
* [gdb/testsuite] Require DW_LNE_end_sequenceTom de Vries2024-04-173-0/+17
| | | | | | | | | | | | | | The dwarf standard requires that every line number program sequence ends with a DW_LNE_end_sequence instruction. Enforce this in the dwarf assembler for the last sequence in a line number program (we have no means to enforce this for earlier sequences), and fix a few test-case that don't have it. Tested on aarch64-linux. PR testsuite/31618 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31618
* [gdb/testsuite] Fix end_sequence addressesTom de Vries2024-04-178-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: ... 00000000004102c4 <end_of_sequence>: 4102c4: 52800000 mov w0, #0x0 // #0 4102c8: 9100c3ff add sp, sp, #0x30 4102cc: d65f03c0 ret ... is not described by the line table: ... File name Line number Starting address View Stmt ... map-to-same-line.c 54 0x4102ac x map-to-same-line.c - 0x4102c4 ... Fix this by ending the line table at $main_end. Likewise in a few other test-cases, found using: ... $ find gdb/testsuite/ -type f \ | xargs grep -B1 DW_LNE_end_sequence \ | grep set_address \ | egrep -v "_end|_len" ... Tested on aarch64-linux.