aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.dwarf2
AgeCommit message (Collapse)AuthorFilesLines
2023-01-13Rename to allow_shlib_testsTom Tromey2-2/+2
This changes skip_shlib_tests to invert the sense, and renames it to allow_shlib_tests.
2023-01-13Rename to allow_python_testsTom Tromey2-4/+4
This changes skip_python_tests to invert the sense, and renames it to allow_python_tests.
2023-01-13Rename to allow_fortran_testsTom Tromey1-1/+1
This changes skip_fortran_tests to invert the sense, and renames it to allow_fortran_tests.
2023-01-13Rename to allow_cplus_tests and allow_stl_testsTom Tromey18-18/+18
This changes skip_cplus_tests to invert the sense, and renames it to allow_cplus_tests. This one also converts skip_stl_tests to allow_stl_tests, as that was convenient to do at the same time.
2023-01-13Use "require" for Python testsTom Tromey1-7/+1
This changes various tests to use "require" for the Python feature.
2023-01-13Use require is_c_compiler_gccTom Tromey19-67/+19
This changes some tests to use "require is_c_compiler_gcc".
2023-01-13Use require !use_gdb_stubTom Tromey1-4/+1
This changes some tests to use "require !use_gdb_stub".
2023-01-13Use require !skip_fortran_testsTom Tromey1-3/+1
This changes some tests to use "require !skip_fortran_tests".
2023-01-13Use require !skip_shlib_testsTom Tromey2-8/+2
This changes some tests to use "require !skip_shlib_tests".
2023-01-13Use require !skip_cplus_testsTom Tromey18-28/+18
This changes some tests to use "require !skip_cplus_tests".
2023-01-13Use require is_x86_like_targetTom Tromey5-21/+5
This changes some tests to use "require is_x86_like_target".
2023-01-13Use require dwarf2_supportTom Tromey203-620/+203
This changes some tests to use "require dwarf2_support".
2023-01-13Change 'require' to accept a list of predicatesTom Tromey3-3/+3
This changes 'require' to accept a list of simple predicates. For now, each predicate is just the name of a proc, optionally prefixed with "!" to indicate that the result should be inverted. It's possible to make this fancier, but so far I haven't done so. One idea I had is to allow a predicate to have associated text to display on failure. Another is to convert the predicates that need a running gdb (e.g., skip_python_tests) to start their own gdb, and then 'require' could enforce the rule that gdb not be running when it is called.
2023-01-13Don't use ensure_gdb_index with requireTom Tromey4-4/+16
This series changes 'require' to take a list of simple predicates. This patch backs out the one use of 'require' that doesn't conform to this -- calling ensure_gdb_index.
2023-01-10gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.Rohr, Stephan1-1/+51
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-01Update copyright year range in header of all files managed by GDBJoel Brobecker434-434/+434
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-05gdb/testsuite: remove perror calls when failing to runSimon Marchi2-2/+0
I noticed that when running these two tests in sequence: Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ... ERROR: GDB process no longer exists ERROR: Couldn't run foo-all Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ... The results in gdb.sum are: Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ... PASS: gdb.ada/arrayptr.exp: scenario=all: compilation foo.adb ERROR: GDB process no longer exists UNRESOLVED: gdb.ada/arrayptr.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:40 (eof) ERROR: Couldn't run foo-all Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ... UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1 The UNRESOLVED for arrayptr.exp is fine, as GDB crashes in that test, while trying to run to main. However, the UNRESOLVED in assign_1.exp doesn't make sense, GDB behaves as expected in that test: (gdb) set lang ada^M (gdb) UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada print $xxx := 1^M $1 = 1^M (gdb) PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1 The problem is that arrayptr.exp calls perror when failing to run to main, then returns. perror makes it so that the next test (as in pass/fail) will be recorded as UNRESOLVED. However, here, the next test (as in pass/fail) is in the next test (as in .exp). Hence the spurious UNRESOLVED in assign_1.exp. These perror when failing to run to X are not really useful, especially since runto records a FAIL on error, by default. Remove all the perrors on runto failure I could find. When there wasn't one already, add a return statement when failing to run, to avoid running the test of the test unnecessarily. I thought of adding a check ran between test (in gdb_finish probably) where we would emit a warning if errcnt > 0, meaning a test quit and left a perror "active". However, reading that variable would poke into the DejaGNU internals, not sure it's a good idea. Change-Id: I2203df6d06e199540b36f56470d1c5f1dc988f7b
2022-12-01Add name canonicalization for CTom Tromey1-3/+3
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-11-28gdb/testsuite: remove use of then keyword from gdb.*/*.exp scriptsAndrew Burgess5-6/+6
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's still a bunch of places in the testsuite where we make use of the 'then' keyword, and sometimes these get copies into new tests, which just spreads poor practice. This commit removes all use of the 'then' keyword from the remaining gdb.*/*.exp scripts. Previous commits have done the bulk of this removal, this commit just handles the remaining directories that each contain a low number of instances. There should be no changes in what is tested after this commit.
2022-11-28gdb/testsuite: fail if gdb_start_cmd failsSimon Marchi1-1/+6
I broke gdb.ada/start.exp, and did not notice it, because it outputs an UNTESTED if gdb_start_cmd fails. I don't really see when start would fail and it's not a problem that should be looked at. Change all spots that call untested after a gdb_start_cmd failure, use fail instead. Doing so caused some failures with the native-gdbserver board. Some tests that use "start" were relying on the fact that start would fail with that board to just return with "untested". Change them to add an early return if use_gdb_stub returns true. Some gdb.pascal tests also failed with native-gdbserver, because they did use gdb_start_cmd to start the inferior, for no good reason. Convert them to use runto_main instead, which does the right thing if the target is a stub. A further refactoring could be to make gdb_start_cmd match the expected breakpoint hit and the prompt, which it doesn't do currently (it leaves that to the callers, but not all of them do). Change-Id: I097370851213e798ff29fb6cf8ba25ef7d2be007 Reviewed-By: Bruno Larsen <blarsen@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2022-11-26[gdb/symtab] Handle failure to open .gnu_debugaltlink fileTom de Vries1-0/+48
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-22gdb/testsuite: remove gcc restriction from gdb.dwarf2/clang-cli-macro.expBruno Larsen1-3/+0
With the recent changes to the dwarf assembler, there is no longer a need to test for gcc in gdb.dwarf2/clang-cli-macro.exp and mark it as untested. This commit removes that logic.
2022-11-03gdb: Fix issue with Clang CLI macrosBruno Larsen2-0/+118
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-25[gdb/testsuite] Handle missing .note.GNU-stackTom de Vries54-0/+54
On openSUSE Tumbleweed I run into this for the dwarf assembly test-cases, and some hardcoded assembly test-cases: ... Running gdb.dwarf2/fission-absolute-dwo.exp ... gdb compile failed, ld: warning: fission-absolute-dwo.o: \ missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future \ version of the linker === gdb Summary === # of untested testcases 1 ... Fix the dwarf assembly test-cases by adding the missing .note.GNU-stack in proc Dwarf::assemble. Fix the hard-coded test-cases using this command: ... $ for f in $(find gdb/testsuite/gdb.* -name *.S); do if ! grep -q note.GNU-stack $f; then echo -e "\t.section\t.note.GNU-stack,\"\",@progbits" >> $f; fi; done ... Likewise for .s files, and gdb/testsuite/lib/my-syscalls.S. The idiom for arm seems to be to use %progbits instead, see commit 9a5911c08be ("gdb/testsuite/gdb.dwarf2: Replace @ with % for ARM compatability"), so hand-edit gdb/testsuite/gdb.arch/arm-disp-step.S to use %progbits instead. Note that dwarf assembly testcases use %progbits as decided by proc _section. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29674
2022-10-19gdb/testsuite: avoid creating files in gdb/testsuite directoryAndrew Burgess1-1/+1
I spotted that the test gdb.dwarf2/dw2-using-debug-str.exp was creating an output file called debug_str_section in the root build/gdb/testsuite directory instead of using the build/gdb/testsuite/output/gdb.dwarf2/dw2-using-debug-str/ directory. This appears to be caused by a missing '$' character. We setup a variable debug_str_section which contains a path within the output directory, but then when we build the objcopy command we use 'debug_str_section' without a '$' prefix, as a result, we create the debug_str_section file. This commit adds the missing '$', the file is now created in the output directory.
2022-10-14[gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with clangTom de Vries1-1/+1
With test-case gdb.base/infoline-reloc-main-from-zero.exp and clang I run into: ... gdb compile failed, clang-13.0: warning: -e main: 'linker' input unused \ [-Wunused-command-line-argument] clang-13.0: warning: -Wl,-Ttext=0x00: 'linker' input unused \ [-Wunused-command-line-argument] clang-13.0: warning: -Wl,-N: 'linker' input unused \ [-Wunused-command-line-argument] UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \ infoline-reloc-main-from-zero.exp UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: failed to compile ... Fix this by using ldflags instead of additional_flags. Likewise, fix all occurrences of: ... $ find gdb/testsuite -name *.exp | xargs grep additional_flags.*Wl ... Tested on x86_64-linux.
2022-10-13[gdb/testsuite] Fix gdb.dwarf2/entry-value-typedef.exp with -m32Tom de Vries1-1/+1
With test-case gdb.dwarf2/entry-value-typedef.exp and target board unix/-m32, I run into: ... builtin_spawn -ignore SIGHUP g++ -fno-stack-protector \ gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S \ -fdiagnostics-color=never -Lbuild/libiberty -lm -m32 \ -o outputs/gdb.dwarf2/entry-value-typedef/entry-value-typedef^M entry-value-typedef.cpp: Assembler messages:^M entry-value-typedef.cpp:38: Error: bad register name `%rbp'^M ... The problem is that the test-cases selects an amd64 .S file based on the check: ... if { [istarget "x86_64-*-linux*"] } { ... which is also true for target board unix/-m32 on x86_64-linux. Fix this by adding the missing is_lp64_target check. Tested on x86_64-linux, using native and target board unix/-m32.
2022-10-12[gdb/testsuite] Silence warnings about obsolete -gstabsTom de Vries1-1/+1
When running test-case gdb.base/gdbindex-stabs.exp on openSUSE Tumbleweed (with gcc 12) I get: ... gdb compile failed, gdb/testsuite/gdb.base/gdbindex-stabs.c: warning: \ STABS debugging information is obsolete and not supported anymore ... Silence the warning by passing quiet to gdb_compile. Likewise in two other test-cases.
2022-10-12[gdb/testsuite] Remove unnecessary perror in some test-casesTom de Vries2-2/+0
On openSUSE Tumbleweed I noticed: ... UNTESTED: gdb.dwarf2/fission-absolute-dwo.exp: fission-absolute-dwo.exp ERROR: failed to compile fission-absolute-dwo ... The ERROR is unnecessary, given that an UNTESTED is already emitted. Furthermore, it could be argued that it is incorrect because it's not a testsuite error to not be able to compile something, and UNTESTED or UNSUPPORTED is more appropriate. Remove the perror call, likewise in fission-relative-dwo.exp. Tested on x86_64-linux.
2022-10-07[gdb/testsuite] Fix DUPLICATEs with remote-gdbserver-on-localhostTom de Vries1-60/+64
Fix some DUPLICATEs that we run into with target board remote-gdbserver-on-localhost, by using test_with_prefix. Tested on x86_64-linux, with native and target board remote-gdbserver-on-localhost.
2022-10-04[gdb/symtab] Don't complain about function declsTom de Vries2-0/+64
[ 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 Vries2-0/+66
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-30[gdb/testsuite] Add aranges to gdb.dwarf2/dw2-dir-file-name.expTom de Vries1-0/+16
Since commit 52b920c5d20 ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for ppc64le"), the test-case fails with target board cc-with-debug-names, due to missing .debug_aranges info. Add the missing .debug_aranges info. Also add a file_id option to Dwarf::assemble, to make it possible to contribute to an already open file. Tested on x86_64-linux.
2022-09-26[gdb/testsuite] Fix gdb.dwarf2/dw2-unspecified-type-foo.c with -m32Tom de Vries1-0/+1
When running test-case gdb.dwarf2/dw2-unspecified-type-foo.c with target board unix/-m32, I run into: ... (gdb) PASS: gdb.dwarf2/dw2-unspecified-type.exp: ptype foo p ((int (*) ()) foo) ()^M $1 = -135698472^M ... Add the missing "return 0" in foo, which fixes this. Tested on x86_64-linux.
2022-09-17[gdb/symtab] Fix "file index out of range" complaintTom de Vries2-0/+49
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 Vries2-0/+68
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-16[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for aarch64Tom de Vries1-5/+12
[ Another attempt at fixing the problem described in commit cd919f5533c ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"). ] When running the test-case gdb.dwarf2/dw2-dir-file-name.exp with aarch64-linux, we run into: ... (gdb) continue^M Continuing.^M ^M Breakpoint 2, compdir_missing__ldir_missing__file_basename () at \ tmp-dw2-dir-file-name.c:999^M (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ compdir_missing__ldir_missing__file_basename ... The breakpoint set at compdir_missing__ldir_missing__file_basename_label, address 0x400608 starts at a line entry: ... CU: tmp-dw2-dir-file-name.c: File name Line number Starting address View Stmt tmp-dw2-dir-file-name.c 999 0x400608 x tmp-dw2-dir-file-name.c 1000 0x40062c x tmp-dw2-dir-file-name.c - 0x40062c ... and therefore the breakpoint is printed without instruction address. In contrast, for x86_64-linux, we have the breakpoint printed with instruction address: ... (gdb) continue^M Continuing.^M ^M Breakpoint 2, 0x004004c1 in compdir_missing__ldir_missing__file_basename () \ at tmp-dw2-dir-file-name.c:999^M (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ compdir_missing__ldir_missing__file_basename ... The breakpoint set at compdir_missing__ldir_missing__file_basename_label, address 0x004004c1 doesn't start at a line entry: ... CU: tmp-dw2-dir-file-name.c: File name Line number Starting address View Stmt tmp-dw2-dir-file-name.c 999 0x4004bd x tmp-dw2-dir-file-name.c 1000 0x4004d3 x tmp-dw2-dir-file-name.c - 0x4004d3 ... Fix this by: - unifying behaviour between the archs by adding an explicit line number entry for the address compdir_missing__ldir_missing__file_basename_label, making the FAIL reproducible on x86_64-linux. - expecting the breakpoint to be printed without instruction address. Tested on x86_64-linux and aarch64-linux.
2022-09-12[gdb/symtab] Support .gdb_index section with TUs in .debug_infoTom de Vries2-0/+70
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-12[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for ppc64leTom de Vries1-4/+4
In commit cd919f5533c ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"), I made gdb.dwarf2/dw2-dir-file-name.exp independent of prologue analyzers, using this change: ... - gdb_breakpoint $func + gdb_breakpoint *$func ... That however caused a regression on ppc64le. For PowerPC, as described in the ELFv2 ABI, a function can have a global and local entry point. Setting a breakpoint on *$func effectively creates a breakpoint for the global entry point, so if the function is entered through the local entry point, the breakpoint doesn't trigger. Fix this by reverting commit cd919f5533c, and setting the breakpoint on ${func}_label instead. Tested on x86_64-linux and ppc64le-linux.
2022-09-12[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp with clangTom de Vries2-23/+62
When running test-case gdb.dwarf2/dw2-dir-file-name.exp with clang, we run into: ... (gdb) break *compdir_missing__ldir_missing__file_basename^M Breakpoint 2 at 0x400580^M (gdb) continue^M Continuing.^M ^M Breakpoint 2, 0x0000000000400580 in \ compdir_missing.ldir_missing.file_basename ()^M (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ compdir_missing__ldir_missing__file_basename ... The problem is that the test-case uses labels outside functions, which is know to cause problem with clang, as documented in the comment for proc function_range. Fix this by using get_func_info instead. Tested on x86_64-linux, with both gcc 7.5.0 and clang 13.0.0.
2022-09-11[gdb/symtab] Fix handling of DW_TAG_unspecified_typeTom de Vries3-0/+119
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
2022-09-06[gdb/symtab] Support .debug_names section with TUs in .debug_infoTom de Vries3-77/+114
When running test-case gdb.cp/cpexprs-debug-types.exp on target board cc-with-debug-names/gdb:debug_flags=-gdwarf-5, we get an executable with a .debug_names section, but no .debug_types section. For dwarf-5, the TUs are no longer put in a separate unit, but instead they're put in the .debug_info section. When loading the executable, the .debug_names section is silently ignored because of this check in dwarf2_read_debug_names: ... if (map->tu_count != 0) { /* We can only handle a single .debug_types when we have an index. */ if (per_bfd->types.size () != 1) return false; ... which triggers because per_bfd->types.size () == 0. The intention of the check is to make sure we don't have more that one .debug_types section, as can happen in a object file (see PR12984): ... $ grep "\.debug_types" 11.s .section .debug_types,"G",@progbits,wt.75c042c23a9a07ee,comdat .section .debug_types,"G",@progbits,wt.c59c413bf50a4607,comdat ... Fix this by: - changing the check condition to "per_bfd->types.size () > 1", and - handling per_bfd->types.size () == 0. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29385
2022-09-06[gdb/testsuite] Add gdb.dwarf2/debug-names-bad-cu-index.expTom de Vries1-0/+90
Add test-case gdb.dwarf2/debug-names-bad-cu-index.exp, a regression test for commit 2fe9a3c41fa ("[gdb/symtab] Fix bad compile unit index complaint"). Tested on x86_64-linux.
2022-09-06[gdb/testsuite] Add gdb.dwarf2/debug-names-tu.expTom de Vries1-0/+93
Add a test-case gdb.dwarf2/debug-names-tu.exp, that uses the dwarf assembler to specify a .debug_names index with the TU list referring to a TU from the .debug_types section. This is intended to produce something similar to: ... $ gcc -g -fdebug-types-section ~/hello.c -gdwarf-4 $ gdb-add-index -dwarf-5 a.out ... Tested on x86_64-linux.
2022-08-31gdb, dwarf: create symbols for template tags without namesNils-Christian Kempke2-0/+228
The following GDB behavior was also reported as a GDB bug in https://sourceware.org/bugzilla/show_bug.cgi?id=28396 I will reiterate the problem a bit and give some more information here. This patch closes the above mentioned bug. The DWARF 5 standard 2.23 'Template Parameters' reads: A template type parameter is represented by a debugging information entry with the tag DW_TAG_template_type_parameter. A template value parameter is represented by a debugging information entry with the tag DW_TAG_template_value_parameter. The actual template parameter entries appear in the same order as the corresponding template formal parameter declarations in the source progam. A type or value parameter entry may have a DW_AT_name attribute, whose value is a null-terminated string containing the name of the corresponding formal parameter. So the DW_AT_name attribute for DW_TAG_template_type_parameter and DW_TAG_template_value_parameter is optional. Within GDB, creating a new symbol from some read DIE usually requires the presence of a DW_AT_name for the DIE (an exception here is the case of unnamed namespaces or the existence of a linkage name). This patch makes the presence of the DW_AT_name for template value/type tags optional, similar to the unnamed namespaces. For unnamed namespaces dwarf2_name simply returns the constant string CP_ANONYMOUS_NAMESPACE_STR '(anonymous namespace)'. For template tags a case was added to the switch statement calling the unnamed_template_tag_name helper. Within the scope of parent which the template parameter is a child of, the helper counts the position of the template tag within the unnamed template tags and returns '<unnamedNUMBER>' where NUMBER is its position. This way we end up with unique names within the respective scope of the function/class/struct (these are the only currenltly supported template kinds within GDB and usually the compilers) where we discovered the template tags in. While I do not know of a way to bring GCC to emit template tags without names there is one for clang/icpx. Consider the following example template<typename A, typename B, typename C> class Foo {}; template<typename, typename B, typename> class Foo; int main () { Foo<double, int, float> f; return 0; } The forward declaration for 'Foo' with the missing template type names 'A' and 'C' makes clang emit a bunch of template tags without names: ... <2><43>: Abbrev Number: 3 (DW_TAG_variable) <44> DW_AT_location : 2 byte block: 91 78 (DW_OP_fbreg: -8) <47> DW_AT_name : (indirect string, offset: 0x63): f <4b> DW_AT_decl_file : 1 <4c> DW_AT_decl_line : 8 <4d> DW_AT_type : <0x59> ... <1><59>: Abbrev Number: 5 (DW_TAG_class_type) <5a> DW_AT_calling_convention: 5 (pass by value) <5b> DW_AT_name : (indirect string, offset: 0x74): Foo<double, int, float> <5f> DW_AT_byte_size : 1 <60> DW_AT_decl_file : 1 <61> DW_AT_decl_line : 2 <2><62>: Abbrev Number: 6 (DW_TAG_template_type_param) <63> DW_AT_type : <0x76> <2><67>: Abbrev Number: 7 (DW_TAG_template_type_param) <68> DW_AT_type : <0x52> <6c> DW_AT_name : (indirect string, offset: 0x6c): B <2><70>: Abbrev Number: 6 (DW_TAG_template_type_param) <71> DW_AT_type : <0x7d> ... Befor this patch, GDB would not create any symbols for the read template tag DIEs and thus lose knowledge about them. Breaking at the return statement and printing f's type would read (gdb) ptype f type = class Foo<double, int, float> [with B = int] { <no data fields> } After this patch GDB does generate symbols from the DWARF (with their artificial names: (gdb) ptype f type = class Foo<double, int, float> [with <unnamed0> = double, B = int, <unnamed1> = float] { <no data fields> } The same principle theoretically applies to template functions. Also here, GDB would not record unnamed template TAGs but I know of no visual way to trigger and test this changed behavior. Template functions do not emit a '[with...]' list and their name generation also does not suffer from template tags without names. GDB does not check whether or not a template tag has a name in 'dwarf2_compute_name' and thus, the names of the template functions are created independently of whether or not the template TAGs have a DW_TAT_name attribute. A testcase has been added in the gdb.dwarf2 for template classes and structs. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28396
2022-08-30[gdb/symtab] Fix assert in set_lengthTom de Vries1-0/+80
When running the included test-case, we run into: ... (gdb) break _start^M read.h:309: internal-error: set_length: \ Assertion `m_length == length' failed.^M ... The problem is that while there are two CUs: ... $ readelf -wi debug-names-missing-cu | grep @ Compilation Unit @ offset 0x0: Compilation Unit @ offset 0x2d: ... the CU table in the .debug_names section only contains the first one: ... CU table: [ 0] 0x0 ... The incomplete CU table makes create_cus_from_debug_names_list set the size of the CU at 0x0 to the actual size of both CUs combined. This eventually leads to the assert, when we read the actual size from the CU header. While having an incomplete CU table in a .debug_names section is incorrect, we need a better failure mode than asserting. The easiest way to fix this is to set the length to 0 (meaning: unkown) in create_cus_from_debug_names_list. This makes the failure mode to accept the incomplete CU table, but to ignore the missing CU. It would be nice to instead reject the .debug_names index, and build a complete CU list, but the point where we find this out is well after dwarf2_initialize_objfile, so it looks rather intrusive to restart at that point. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29453
2022-08-19gdb/testsuite: re-compile entry-value-typedef .S files with -fPIESimon Marchi2-54/+64
As Luis pointed out here [1], the AArch64 variant of the test doesn't work on systems that use PIE by default. For example, on this Debian 11: $ make check TESTS="gdb.dwarf2/entry-value-typedef.exp" gdb compile failed, /usr/bin/ld: /tmp/ccJE8ZSr.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccJE8ZSr.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' This is because entry-value-typedef-aarch64.S was generated on an old system that does not generate position-independent code by default, but the system the test runs on tries to link the test executable as position-independent. Fix this by regenerating the same binary on the same system as the original one, but with -fPIE this time. Do the same for the amd64 binary, although this one was already position-independent so the generated code doesn't change. With this patch applied, the test passes on the Debian 11 AArch64 system. [1] https://sourceware.org/pipermail/gdb-patches/2022-August/191462.html Change-Id: I68d55adaa56a7a3eddb0c13980b1a98b791f8144
2022-08-18gdb: call check_typedef at beginning of dwarf_expr_context::fetch_resultSimon Marchi4-0/+28511
Bug 29374 shows this crash: $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out ... /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed. The backtrace is: #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51 #1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217 #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040 #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091 #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485 #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529 #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235 #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332 #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365 #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889 #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559 #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887 #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390 #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116 #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079 #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198 The problem is that the type that gets passed down to dwarf_expr_context::fetch_result (the type of a variable of which we're trying to read the entry value) is a typedef whose size has never been computed yet (check_typedef has never been called on it). As we get in the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len` variable is therefore set to 0, instead of the actual type length. We then call allocate_value on subobj_type, which does call check_typedef, so the length of the typedef gets filled in at that point. We end up passing to the copy function a source array view of length 0 and a target array view of length 4, and the assertion fails. Fix this by calling check_typedef on both type and subobj_type at the beginning of fetch_result. I tried writing a test for this using the DWARF assembler, but I haven't succeeded. It's possible that we need to get into this specific code path (value_of_dwarf_reg_entry and all) to manage to get to dwarf_expr_context::fetch_result with a typedef type that has never been resolved. In all my attempts, the typedef would always be resolved already, so the bug wouldn't show up. As a fallback, I made a gdb.dwarf2 test with compiler-generated .S files. I don't particularly like those, but I think it's better than no test. The .cpp source code is the smallest reproducer I am able to make from the reproducer given in the bug (thanks to Pedro for suggestions on how to minimize it further than I had). Since I tested on both amd64 and aarch64, I added versions of the test for these two architectures. Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374
2022-08-12[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.expTom de Vries1-4/+4
When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we have: ... (gdb) break compdir_missing__ldir_missing__file_basename^M Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M (gdb) continue^M Continuing.^M ^M Breakpoint 2, 0x00000000004004c4 in \ compdir_missing__ldir_missing__file_basename () \ at tmp-dw2-dir-file-name.c:999^M (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ compdir_missing__ldir_missing__file_basename ... When trying to set a breakpoint on compdir_missing__ldir_missing__file_basename, the architecture-specific prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4: ... 00000000004004c0 <compdir_missing__ldir_missing__file_basename>: 4004c0: 55 push %rbp 4004c1: 48 89 e5 mov %rsp,%rbp 4004c4: 8b 05 72 1b 20 00 mov 0x201b72(%rip),%eax # 60203c <v> 4004ca: 83 c0 01 add $0x1,%eax 4004cd: 89 05 69 1b 20 00 mov %eax,0x201b69(%rip) # 60203c <v> 4004d3: 90 nop 4004d4: 5d pop %rbp 4004d5: c3 ret ... And because the line table info is rudamentary: ... CU: tmp-dw2-dir-file-name.c: File name Line number Starting address View Stmt tmp-dw2-dir-file-name.c 999 0x4004c0 x tmp-dw2-dir-file-name.c 1000 0x4004d6 x tmp-dw2-dir-file-name.c - 0x4004d6 ... the address does not fall at an actual line, so the breakpoint is shown with address, both when setting it and hitting it. when running the test-case with aarch64-linux, we have similarly: ... (gdb) break compdir_missing__ldir_missing__file_basename^M Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M ... due to the architecture-specific prologue skipper starting at 0x400610 and skipping past two insns, to 0x400618: ... 0000000000400610 <compdir_missing__ldir_missing__file_basename>: 400610: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17> 400614: 9100b000 add x0, x0, #0x2c 400618: b9400000 ldr w0, [x0] 40061c: 11000401 add w1, w0, #0x1 400620: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17> 400624: 9100b000 add x0, x0, #0x2c 400628: b9000001 str w1, [x0] 40062c: d503201f nop 400630: d65f03c0 ret ... But interestingly, the aarch64 architecture-specific prologue skipper is wrong. There is no prologue, and the breakpoint should be set at 0x400610. By using "break *compdir_missing__ldir_missing__file_basename" we can get the breakpoint set at 0x400610: ... (gdb) break *compdir_missing__ldir_missing__file_basename^M Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M ... and make the test-case independent of prologue analysis. This requires us to update the expected patterns. The fix ensures that once the aarch64 architecture-specific prologue skipper will be fixed, this test-case won't start failing. Tested on x86_64-linux.
2022-08-09[gdb/testsuite] Fix gdb.dwarf2/debug-names.expTom de Vries1-7/+4
When running test-case gdb.dwarf2/debug-names.exp on openSUSE Tumbleweed, I run into: ... (gdb) maint info symtabs^M ... ERROR: internal buffer is full. UNRESOLVED: gdb.dwarf2/debug-names.exp: break _start expanded symtab ... Fix this by simplifying the test-case to print _start rather running to it. Tested on x86_64-linux.
generated by cgit v1.1 at 2024-07-13 15:12:34 +0000