aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.adaTom de Vries4-16/+31
In gdb.ada we have these duplicate test-names: ... DUPLICATE: gdb.ada/catch_ex.exp: continuing to program completion DUPLICATE: gdb.ada/mi_catch_ex.exp: breakpoint at main DUPLICATE: gdb.ada/mi_catch_ex.exp: mi runto main DUPLICATE: gdb.ada/mi_catch_ex_hand.exp: breakpoint at main DUPLICATE: gdb.ada/mi_catch_ex_hand.exp: mi runto main ... Fix these using with_test_prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.ada/catch_ex.exp: Use with_test_prefix. * gdb.ada/mi_catch_ex.exp: Same. * gdb.ada/mi_catch_ex_hand.exp: Same.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.fortranTom de Vries2-7/+19
In gdb.fortran we have: ... DUPLICATE: gdb.fortran/complex.exp: whatis $ DUPLICATE: gdb.fortran/complex.exp: whatis $ DUPLICATE: gdb.fortran/complex.exp: whatis $ DUPLICATE: gdb.fortran/complex.exp: whatis $ ... Fix this by using with_test_prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.fortran/complex.exp: Use with_test_prefix.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.traceTom de Vries2-3/+7
In gdb.trace we have these duplicates: ... DUPLICATE: gdb.trace/passcount.exp: 4.20a: set all three passcounts to three DUPLICATE: gdb.trace/passcount.exp: 4.6: set passcount to zero DUPLICATE: gdb.trace/passcount.exp: 4.7: set passcount to large number (32767) ... Fix these by fixing the test-names. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.trace/passcount.exp: Fix test-names.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.pascalTom de Vries2-2/+10
In gdb.pascal we have these duplicates: ... DUPLICATE: gdb.pascal/gdb11492.exp: next DUPLICATE: gdb.pascal/gdb11492.exp: print char_array ... Fix these by using with_test_prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.pascal/gdb11492.exp: Use with_test_prefix.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.{gdb,opt,xml}Tom de Vries4-7/+17
There are 3 test directories with one duplicate test-name: gdb.gdb, gdb.opt and gdb.xml. The duplicates are: ... DUPLICATE: gdb.gdb/complaints.exp: call complaint_internal ($cstr) DUPLICATE: gdb.opt/inline-locals.exp: info locals above bar 2 \ (PRMS: gdb/25695) DUPLICATE: gdb.xml/tdesc-regs.exp: ptype $extrareg ... Fix as appropriate. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.gdb/complaints.exp: Use with_test_prefix. * gdb.xml/tdesc-regs.exp: Same. * gdb.opt/inline-locals.exp: Fix test name.
2020-05-12[gdb/testsuite] add jit-elf-util.h and run jit functionMihails Strasuns2-39/+133
Splits ELF related symbols into a separate jit-elf-util.h header and enhances it with a few more. Intention is to make adding new JIT tests possible without repeating most of the common boilerplate. As a test enhancement, jit-elf-main.c now calls the renamed function after registering the jit object and ensures it returns an expected result. gdb/testsuite/ChangeLog: 2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com> * gdb.base/jit-elf-util.h: New header file. * gdb.base/jit-elf-main.c: Use jit-elf-util.h, add a call to the renamed JIT function to verify its result.
2020-05-12[gdb/testsuite] define jit function name via macroMihails Strasuns3-34/+8
Replaces previous approach with patching resulting ELF binary after loading - now that each test iteration works on a separately compiled binary it is not necessary anymore. Tests are still being ran without debug info to preserve original test functionality but this change opens up the possibility to enable debug info if needed too. gdb/testsuite/ChangeLog: 2020-03-27 Mihails Strasuns <mihails.strasuns@intel.com> * lib/jit-elf-helpers.exp: Supply -DFUNCTION_NAME macro definition when compiling jit-elf-solib.co. * gdb.base/jit-elf-main.c: Stop patching jit function name. * gdb.base/jit-elf-solib.c: Use FUNCTION_NAME macro value as a function name.
2020-05-12[gdb/testsuite] use -Ttext-segment for jit-elf testsMihails Strasuns2-15/+46
Removes the need to manually relocate loaded ELF binary by using a fixed constant as both mmap base address and as a requested first segment address supplied to the linker. In future will enable JIT tests with a valid DWARF debug info. Current tests still need to compile without a debug info though, because they do a function name modification. gdb/testsuite/ChangeLog: 2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com> * lib/jit-elf-helpers.exp: Supply -Ttext-segment linker flag and define LOAD_ADDRESS/LOAD_INCREMENT macros for the compiled binaries. * gdb.base/jit-elf-main.c: Use LOAD_ADDRESS/LOAD_INCREMENT to calculate the mmap address.
2020-05-12[gdb/testsuite] add lib/jit-elf-helpers.expMihails Strasuns3-106/+93
New utility library to be used by jit-elf tests responsible for compiling binary artifacts. In the next commit the compilation process will become more complicated because of extra mandatory flag - keeping it in one place will make tests less fragile. gdb/testsuite/ChangeLog: 2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com> * lib/jit-elf-helpers.exp: New file. * gdb.base/jit-elf.exp: Updated to use jit-elf-helpers.exp. * gdb.base/jit-elf-so.exp: Updated to use jit-elf-helpers.exp.
2020-05-12[gdb/testsuite] use args as lib list for jit-elf testsMihails Strasuns via Gdb-patches3-142/+252
Old usage: jit-elf-main lib.so 2 New usage: jit-elf-main lib.so.1 lib.so.2 Refactoring necessary to support running tests over multiple jit binaries rather than mapping the same binary muultiple times. gdb/testsuite/ChangeLog: 2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com> * gdb.base/jit-elf-main.c: Read lib list from argc/argv. * gdb.base/jit-elf.exp: Compile N jit libraries and use the list. * gdb.base/jit-elf-so.exp: Ditto.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.dwarf2Tom de Vries6-22/+38
We currently have these duplicate test-names in gdb.dwarf2: ... $ grep ^DUPLICATE: gdb.sum DUPLICATE: gdb.dwarf2/comp-unit-lang.exp: show language DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (int)" DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (void *)" DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (int)" DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (int)" DUPLICATE: gdb.dwarf2/data-loc.exp: ptype foo.array_type DUPLICATE: gdb.dwarf2/varval.exp: get integer valueof "sizeof (int)" DUPLICATE: gdb.dwarf2/varval.exp: get integer valueof "sizeof (void *)" DUPLICATE: gdb.dwarf2/implref-struct.exp: print-object=off: \ set print object off DUPLICATE: gdb.dwarf2/implref-struct.exp: print-object=on: \ set print object on DUPLICATE: gdb.dwarf2/dw2-bad-parameter-type.exp: ptype f ... Fix as appropriate. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/comp-unit-lang.exp: Use with_test_prefix. * gdb.dwarf2/dw2-bad-parameter-type.exp: Same. * gdb.dwarf2/implref-struct.exp: Same. * gdb.dwarf2/varval.exp: Ensure get_sizeof is called once per type. * gdb.dwarf2/data-loc.exp: Same. Remove duplicate test.
2020-05-11gdb: change duplicate test name in gdb.base/jit-so.expSimon Marchi2-1/+6
When running gdb.base/jit-so.exp, we see duplicate test names: $ grep PASS testsuite/gdb.sum | sort | uniq -c | sort -n ... 2 PASS: gdb.base/jit-so.exp: one_jit_test-1: info function jit_function 2 PASS: gdb.base/jit-so.exp: one_jit_test-2: info function jit_function Give an explicit name to one test to avoid this. gdb/testsuite/ChangeLog: * gdb.base/jit-so.exp (one_jit_test): Change test name.
2020-05-11gdb/testsuite: Detect and warn about duplicate test namesAndrew Burgess2-6/+48
Building on the previous commit, this patch detects when two tests have the same test name and causes Dejagnu to print a new result type '# of duplicate test names' in the result summary. A line starting with 'DUPLICATE: ' is also added to the gdb.sum and gdb.log files. The DUPLICATE markers will be printed the second time a duplicate test name is seen, and every time after that. So you might see: PASS: gdb.base/sometest.exp: foo PASS: gdb.base/sometest.exp: bar PASS: gdb.base/sometest.exp: foo DUPLICATE: gdb.base/sometest.exp: foo PASS: gdb.base/sometest.exp: baz PASS: gdb.base/sometest.exp: foo DUPLICATE: gdb.base/sometest.exp: foo However, the results will report a duplicate count of 1, indicating that just one test name (foo) was duplicated. Currently if the tests are run in parallel mode the new result type is not merged into the combined summary file so users will need to run in non-parallel mode to check this result. Similarly, the 'DUPLICATE: ' markers will not be merged into the final gdb.sum file. A later commit will fix this. gdb/testsuite/ChangeLog: * lib/check-test-names.exp (all_test_names): New module variable. (counts): Add 'duplicates' field. (_check_duplicates): New procedure. (check): Also check for duplicates. (do_log_summary): Print duplicates count. (do_reset_vars): Reset counter for duplicate test names, and discard all know test names.
2020-05-11gdb/testsuite: Detect and warn if paths are used in test namesAndrew Burgess3-0/+148
A new library is introduced that hooks into the core of Dejagnu and detects when a test's name includes either the source or build paths. If any offending test names are detected then Dejagnu will print a new result type, '# of paths in test names'. Users should treat this result type just like other bad results types, and aim not to increase this number. As well as displaying the total number of offending tests as part of the final results, a new marker is included in both the gdb.log and gdb.sum files, this marker starts with 'PATH: ', so an offending test would be expected to appear like this: PASS: gdb.base/sometest.exp: Loaded /path/to/build/testsuite/foo.exe PATH: gdb.base/sometest.exp: Loaded /path/to/build/testsuite/foo.exe This should make it easier to track down offending tests. Currently for a local run on my machine, I don't see any offending test names, but it is possible that different targets, or different configurations, might currently be breaking the no paths rule. In order to get this working I have needed to wrap two core Dejagnu functions, log_summary, and reset_vars. Relying on core functions that are not part of any API is always going to be risky, given the relatively slow rate of Dejagnu change this is probably OK for now, and we can possibly upstream some changes to Dejagnu that would allow this functionality to be supported in a more official way later on. Currently if the tests are run in parallel mode the new result type is not merged into the combined summary file so users will need to run in non-parallel mode to check this result. Similarly, the 'PATH: ' markers will not be merged into the combined summary file. A later commit will fix this. gdb/testsuite/ChangeLog: * lib/gdb.exp: Include check-test-names.exp library. * lib/check-test-names.exp: New file.
2020-05-11[gdb/testsuite] Change kfail into xfail in gdb.ada/packed_tagged.expTom de Vries2-2/+6
Test-case gdb.ada/packed_tagged.exp contains a kfail: ... setup_kfail "gnat compiler bug" *-*-* ... Kfails are used to indicate problems in gdb, xfails are used to indicate problems in the environment. A bug in the gnat compiler is a problem in the environment rather than gdb. Fix this by changing the kfail into an xfail. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-11 Tom de Vries <tdevries@suse.de> * gdb.ada/packed_tagged.exp: Change kfail into xfail.
2020-05-11Fix gdb.ada/attr_ref_and_charlit.exp typoKeith Seitz2-1/+5
... introduced by my last commit: -gdb_test "print s'last" " = 3" + gdb_test "print s'last" " = 3Z gdb/testsuite/ChangeLog 2020-05-11 Keith Seitz <keiths@redhat.com> * gdb.ada/attr_ref_and_charlit.exp: Fix typo.
2020-05-11[gdb/testsuite] Fix gdb.cp/cpexprs-debug-types.exp inclusionTom de Vries4-748/+772
When running tests using RUNTESTFLAGS="cpexprs.exp cpexprs-debug-types.exp", we have: ... Running src/gdb/testsuite/gdb.cp/cpexprs-debug-types.exp ... Running src/gdb/testsuite/gdb.cp/cpexprs.exp ... ... In the first test-case, we have -fdebug-types-section as expected: ... Running src/gdb/testsuite/gdb.cp/cpexprs-debug-types.exp ... g++ -fno-stack-protector -fdiagnostics-color=never \ -fdebug-types-section \ -c -g \ -o outputs/gdb.cp/cpexprs-debug-types/cpexprs-debug-types0.o \ src/gdb/testsuite/gdb.cp/cpexprs.cc ... but in the second test-case, we have also have -fdebug-types-section: ... Running src/gdb/testsuite/gdb.cp/cpexprs.exp ... g++ -fno-stack-protector -fdiagnostics-color=never \ -fdebug-types-section \ -c -g -g \ -o outputs/gdb.cp/cpexprs/cpexprs0.o \ src/gdb/testsuite/gdb.cp/cpexprs.cc ... This is due to using a global variable flags, which is set in cpexprs-debug-types.exp and tested for existence in cpexprs.exp. Fix this by using a more robust inclusion mechanism, that is: - move the bulk of the test-case cpexprs.exp to cpexprs.exp.in, - include it from cpexprs.exp and cpexprs-debug-types.exp, and - set flags in both .exp files gdb/testsuite/ChangeLog: 2020-05-11 Tom de Vries <tdevries@suse.de> * gdb.cp/cpexprs.exp: Move everything except flags setting ... * gdb.cp/cpexprs.exp.in: .. here. * gdb.cp/cpexprs-debug-types.exp: Include cpexprs.exp.in instead of cpexprs.exp.
2020-05-11Clean-up gdb.ada test namesKeith Seitz16-47/+86
This patch fixes all duplicate and tail parentheses test names. These can really hinder automated test analysis such as used by the buildbot. Before: $ cat testsuite/gdb.sum | egrep "^(PASS|FAIL|XPASS|XFAIL|KPASS|KFAIL)" \ | sort | uniq -c | sort -n | grep -v " 1 " 2 PASS: gdb.ada/attr_ref_and_charlit.exp: print s'last 2 PASS: gdb.ada/bp_on_var.exp: set breakpoint pending off 2 PASS: gdb.ada/complete.exp: complete p pck.inne 2 PASS: gdb.ada/fun_overload_menu.exp: multiple matches for f (f (1, null)) 2 PASS: gdb.ada/type_coercion.exp: p q 2 PASS: gdb.ada/unc_arr_ptr_in_var_rec.exp: print My_P_Object.Ptr when no longer null 3 PASS: gdb.ada/fun_overload_menu.exp: 1 After: <empty> For parentheses, I've audited all occurrences of trailing parentheses. Most offenders are of the form: gdb_test "p func (..)" $expected_result I've either added a unique test name or simply removed the whitespace between the function name and the argument list. gdb/testsuite/ChangeLog 2020-05-11 Keith Seitz <keiths@redhat.com> * gdb.ada/arrayparam.exp: Resolve duplicate and tail parentheses test names. * gdb.ada/arrayptr.exp: Likewise. * gdb.ada/assign_arr.exp: Likewise. * gdb.ada/attr_ref_and_charlit.exp: Likewise. * gdb.ada/bp_on_var.exp: Likewise. * gdb.ada/call_pn.exp: Likewise. * gdb.ada/complete.exp: Likewise. * gdb.ada/fun_overload_menu.exp: Likewise. * gdb.ada/funcall_param.exp: Likewise. * gdb.ada/funcall_ref.exp: Likewise. * gdb.ada/packed_array_assign.exp: Likewise. * gdb.ada/same_component_name.exp: Likewise. * gdb.ada/type_coercion.exp: Likewise. * gdb.ada/unc_arr_ptr_in_var_rec.exp: Likewise. * gdb.ada/variant_record_packed_array.exp: Likewise.
2020-05-11[gdb/symtab] Fix incomplete CU list assert in .debug_namesTom de Vries6-107/+229
Consider the following two-file test-case: ... $ cat main.c extern int foo (void); int main (void) { int sum, a, b; sum = a + b + foo (); return sum; } $ cat foo.c int foo (void) { return 3; } ... Compiled like this: ... $ clang-10 -gdwarf-5 -gpubnames -c main.c $ clang-10 -gdwarf-5 -c foo.c $ clang-10 -gdwarf-5 -gpubnames main.o foo.o ... When loading this exec into gdb, we run into this assert: ... $ gdb a.out Reading symbols from a.out... warning: Section .debug_aranges in a.out entry at offset 0 \ debug_info_offset 0 does not exists, ignoring .debug_aranges. src/gdb/dwarf2/read.c:6949: \ internal-error: cutu_reader::cutu_reader(dwarf2_per_cu_data*, \ abbrev_table*, int, bool): \ Assertion `this_cu->length == cu->header.get_length ()' failed. ... The problem is that the determined length of the CU: ... (gdb) p /x this_cu->length $4 = 0x26a ... does not match the actual length: ... (gdb) p /x cu->header.get_length () $5 = 0x59 ... The length of the CU is determined in create_cus_from_debug_names_list, and set based on this list in the .debug_names section: ... Compilation Unit offsets [ CU[0]: 0x000000c7 ] ... and it is assumed that this is a complete list, so the size of the CU is calculated using the end of the .debug_section at 0x331, making it 0x331 - 0xc7 == 0x26a. However, the CU list is not complete: ... $ llvm-dwarfdump -debug-info a.out \ | grep "Compile Unit" \ | sed 's/Compile Unit.*//' 0x00000000: 0x0000002e: 0x000000a5: 0x000000c7: 0x00000120: 0x00000157: 0x0000030f: ... In particular, because the CU for foo.c is there at 0x120 (the rest of the CUs is due to openSUSE having debug info for various linked in objects). Fix the assert by not assuming to know the length of CUs in create_cus_from_debug_names_list (if the .debug_names is not produced by GDB), and setting it to 0, and setting it later to the actual length. Note that this does not fix the .debug_aranges warning, that's PR25969. Build and tested on x86_64-linux, with native and debug-names. gdb/ChangeLog: 2020-05-11 Tom de Vries <tdevries@suse.de> PR symtab/25941 * dwarf2/read.c (create_cus_from_debug_names_list): Initialize CUs with length 0, if not gdb-produced. (cutu_reader::cutu_reader): Set CU length to actual length if 0. gdb/testsuite/ChangeLog: 2020-05-11 Tom de Vries <tdevries@suse.de> PR symtab/25941 * gdb.dwarf2/clang-debug-names.exp.in: New include exp file, factored out of ... * gdb.dwarf2/clang-debug-names.exp: ... here. * gdb.dwarf2/clang-debug-names-2.exp: New file. Include clang-debug-names.exp.in. * gdb.dwarf2/clang-debug-names-2-foo.c: New test. * gdb.dwarf2/clang-debug-names-2.c: New test.
2020-05-11gdb/fortran: Allow Flang MAIN_ in Fortran testingAlok Kumar Sharma40-64/+145
Name of fortran main function for Flang compiler is MAIN_ while for gfortran it is MAIN__ . In test cases MAIN__ is hardcoded for the purpose of inserting breakpoint. New proc is added to detect main function name depending on the compiler used. Fortran specific version of runto_main named fortran_runto_main is added. This commit adds support for Flang main function, there should be no change for gfortran. gdb/testsuite/ChangeLog * lib/fortran.exp (fortran_main): New Proc, handle flang MAIN_, (fortran_runto_main): New Proc, fortran version of runto_main. * gdb.fortran/array-bounds-high.exp: Handle flang MAIN_. * gdb.fortran/array-bounds.exp: Likewise. * gdb.fortran/array-slices.exp: Likewise. * gdb.fortran/block-data.exp: Likewise. * gdb.fortran/charset.exp: Likewise. * gdb.fortran/common-block.exp: Likewise. * gdb.fortran/complex.exp: Likewise. * gdb.fortran/derived-type-function.exp: Likewise. * gdb.fortran/derived-type.exp: Likewise. * gdb.fortran/info-modules.exp: Likewise. * gdb.fortran/info-types.exp: Likewise. * gdb.fortran/intrinsics.exp: Likewise. * gdb.fortran/library-module.exp: Likewise. * gdb.fortran/logical.exp: Likewise. * gdb.fortran/max-depth.exp: Likewise. * gdb.fortran/module.exp: Likewise. * gdb.fortran/multi-dim.exp: Likewise. * gdb.fortran/nested-funcs.exp: Likewise. * gdb.fortran/print-formatted.exp: Likewise. * gdb.fortran/print_type.exp: Likewise. * gdb.fortran/printing-types.exp: Likewise. * gdb.fortran/ptr-indentation.exp: Likewise. * gdb.fortran/ptype-on-functions.exp: Likewise. * gdb.fortran/subarray.exp: Likewise. * gdb.fortran/vla-alloc-assoc.exp: Likewise. * gdb.fortran/vla-datatypes.exp: Likewise. * gdb.fortran/vla-history.exp: Likewise. * gdb.fortran/vla-ptr-info.exp: Likewise. * gdb.fortran/vla-ptype-sub.exp: Likewise. * gdb.fortran/vla-ptype.exp: Likewise. * gdb.fortran/vla-sizeof.exp: Likewise. * gdb.fortran/vla-type.exp: Likewise. * gdb.fortran/vla-value-sub-arbitrary.exp: Likewise. * gdb.fortran/vla-value-sub-finish.exp: Likewise. * gdb.fortran/vla-value-sub.exp: Likewise. * gdb.fortran/vla-value.exp: Likewise. * gdb.fortran/whatis_type.exp: Likewise. * gdb.mi/mi-var-child-f.exp: Likewise.
2020-05-09Fix for the complaint observed when symbol reading due to unsupported ↵nitachra2-12/+5
.debug_names form Following complaint is observed with the executable compiled with -gdwarf-5 and -gpubnames flags - "During symbol reading: Unsupported .debug_names form DW_FORM_ref4". This is the form corresponding to DW_IDX_die_offset attribute. This patch fixes this complaint. Tested with clang 10.0.0. Test case used - int main() { int sum,a,b; sum = a + b; return sum; } clang -gdwarf-5 -gpubnames test.c -o test.out gdb -q test.out -ex "set complaints 1" -ex "start" Reading symbols from test.out... During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \ [in module test.out] Temporary breakpoint 1 at 0x400484 Starting program: test.out During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \ [in module test.out] During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \ [in module test.out] During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \ [in module test.out] gdb/dwarf2/ChangeLog: 2020-05-09 Nitika Achra <Nitika.Achra@amd.com> PR symtab/25952 * read.c (dw2_debug_names_iterator::next): Handle DW_FORM_ref* and DW_IDX_die_offset. If there is no compilation unit attribute in the index entry, then there is a single CU. Return the CU at O index of compilation unit vector. gdb/testsuite/ChangeLog: 2020-05-09 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/clang-debug-names.exp: Remove PR25952 kfail.
2020-05-08[gdb/testsuite] Add gdb.dwarf2/clang-debug-names.cTom de Vries3-0/+186
Add test-case with .debug_names section using DW_FORM_ref4. There's currently no support for .debug_names in the dwarf assembler, so we use plain _emit rather than something more structured. Consequently, we cannot use regular declare_labels-generated labels to refer from .debug_names to .debug_info. Instead, we use labels with a predefined name, which we generate using _compute_label, and then define using define_label. This is the test-case for PR25952, so kfail the corresponding test. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-08 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/clang-debug-names.c: New test. * gdb.dwarf2/clang-debug-names.exp: New file.
2020-05-06gdb: handle endbr64 instruction in amd64_analyze_prologueSimon Marchi4-0/+102
v2: - test: build full executable instead of object - test: add and use supports_fcf_protection - test: use gdb_test_multiple's -wrap option - test: don't execute gdb_assert if failed to get breakpoint address Some GCCs now enable -fcf-protection by default. This is the case, for example, with GCC 9.3.0 on Ubuntu 20.04. Enabling it causes the `endbr64` instruction to be inserted at the beginning of all functions and that breaks GDB's prologue analysis. I noticed this because it gives many failures in gdb.base/break.exp. But let's take this dummy program and put a breakpoint on main: int main(void) { return 0; } Without -fcf-protection, the breakpoint is correctly put after the prologue: $ gcc test.c -g3 -O0 -fcf-protection=none $ ./gdb -q -nx --data-directory=data-directory a.out Reading symbols from a.out... (gdb) disassemble main Dump of assembler code for function main: 0x0000000000001129 <+0>: push %rbp 0x000000000000112a <+1>: mov %rsp,%rbp 0x000000000000112d <+4>: mov $0x0,%eax 0x0000000000001132 <+9>: pop %rbp 0x0000000000001133 <+10>: retq End of assembler dump. (gdb) b main Breakpoint 1 at 0x112d: file test.c, line 3. With -fcf-protection, the breakpoint is incorrectly put on the first byte of the function: $ gcc test.c -g3 -O0 -fcf-protection=full $ ./gdb -q -nx --data-directory=data-directory a.out Reading symbols from a.out... (gdb) disassemble main Dump of assembler code for function main: 0x0000000000001129 <+0>: endbr64 0x000000000000112d <+4>: push %rbp 0x000000000000112e <+5>: mov %rsp,%rbp 0x0000000000001131 <+8>: mov $0x0,%eax 0x0000000000001136 <+13>: pop %rbp 0x0000000000001137 <+14>: retq End of assembler dump. (gdb) b main Breakpoint 1 at 0x1129: file test.c, line 2. Stepping in amd64_skip_prologue, we can see that the prologue analysis, for GCC-compiled programs, is done in amd64_analyze_prologue by decoding the instructions and looking for typical patterns. This patch changes the analysis to check for a prologue starting with the `endbr64` instruction, and skip it if it's there. gdb/ChangeLog: * amd64-tdep.c (amd64_analyze_prologue): Check for `endbr64` instruction, skip it if it's there. gdb/testsuite/ChangeLog: * gdb.arch/amd64-prologue-skip-cf-protection.exp: New file. * gdb.arch/amd64-prologue-skip-cf-protection.c: New file.
2020-05-06[gdb/testsuite] Fix gdb.reverse/consecutive-{precsave,reverse}.exp with gcc-8Tom de Vries3-2/+34
When running test-cases gdb.reverse/consecutive-precsave.exp and gdb.reverse/consecutive-reverse.exp with gcc-8, we get: ... FAIL: gdb.reverse/consecutive-precsave.exp: stopped at bp, 2nd instr FAIL: gdb.reverse/consecutive-reverse.exp: stopped at bp, 2nd instr ... These FAILs are duplicates of the FAILs fixed in commit 7c99e7e2b08 "[gdb/testsuite] Fix gdb.base/consecutive.exp with gcc-8". Fix these in the same manner. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-06 Tom de Vries <tdevries@suse.de> * gdb.reverse/consecutive-precsave.exp: Handle if instruction after breakpoint is at a "recommended breakpoint location". * gdb.reverse/consecutive-reverse.exp: Same.
2020-05-06[gdb/testsuite] Fix gdb.base/watchpoint-reuse-slot.exp with gcc-8Tom de Vries2-2/+7
When running test-case gdb.base/watchpoint-reuse-slot.exp with gcc-8 instead of gcc-7, we have: ... (gdb) PASS: $conf: watch *(buf.byte + 0 + 0)@1 stepi^M -0x00000000004004b9 34 for (i = 0; i < 100000; i++);^M +34 for (i = 0; i < 100000; i++);^M -(gdb) PASS: $conf: stepi advanced +(gdb) FAIL: $conf: stepi advanced ... where $conf is "gdb.base/watchpoint-reuse-slot.exp: hw-watch: always-inserted off: watch x watch: : width 1, iter 0: base + 0". This is due to the fact that gcc-8 generates more precise line info, making the instruction at 0x4004b9 a "recommended breakpoint location", such that gdb no longer prints the instruction address. Fix this by getting the instruction address by printing $pc. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-06 Tom de Vries <tdevries@suse.de> * gdb.base/watchpoint-reuse-slot.exp (stepi): Print $pc to get current address.
2020-05-06[gdb/testsuite] Fix cur_addr update in gdb.base/watchpoint-reuse-slot.expTom de Vries2-1/+5
I noticed this code in gdb.base/watchpoint-reuse-slot.exp, proc stepi: ... gdb_test_multiple "stepi" $test { -re "($hex).*[string_to_regexp $srcline]\r\n$gdb_prompt $" { set addr $expect_out(1,string) if {$addr != $cur_addr} { pass $test } else { fail $test } set cur_addr addr } } ... The variable cur_addr is documented as: ... # The address the program is stopped at currently. set cur_addr "" ... but in the gdb_test_multiple clause we assign the string "addr" to cur_addr, while $addr contains the current address. Fix this by assigning $addr instead "addr". Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-06 Tom de Vries <tdevries@suse.de> * gdb.base/watchpoint-reuse-slot.exp: Fix incorrect assignment.
2020-05-06[gdb/testsuite] Fix gdb.base/store.exp with gcc-10Tom de Vries2-16/+41
When running gdb.base/store.exp with gcc-10 instead of gcc-9, we have: ... (gdb) PASS: gdb.base/store.exp: continue to wack_double print l^M -$22 = <optimized out>^M +$22 = -1^M -(gdb) UNSUPPORTED: gdb.base/store.exp: var double l; print old l, expecting -1 -(gdb) PASS: gdb.base/store.exp: var double l; print old l, expecting -1 +print r^M +$23 = <optimized out>^M +(gdb) FAIL: gdb.base/store.exp: var double l; print old r, expecting -2 ... With gcc-9, there's no location info for both l and r, but with gcc-10, there's location info for l, but not r. The test-case only checks for location info availability of l, and then assumes location info for r is also available. Fix this by allowing missing location info for r. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-06 Tom de Vries <tdevries@suse.de> * gdb.base/store.exp (check_set, up_set): Allowing missing location info for r.
2020-05-06[gdb/testsuite] Fix gdb.base/shlib-call.exp with gcc-8Tom de Vries2-3/+13
When running test-case gdb.base/shlib-call.exp with gcc-8 instead of gcc-7, we have: ... (gdb) step^M -main () at /data/gdb_versions/devel/src/gdb/testsuite/gdb.base/shmain.c:42^M -42 g = mainshr1(g);^M -(gdb) PASS: gdb.base/shlib-call.exp: step out of shr2 epilogue to main +main () at /data/gdb_versions/devel/src/gdb/testsuite/gdb.base/shmain.c:41^M +41 g = shr2(g);^M +(gdb) FAIL: gdb.base/shlib-call.exp: step out of shr2 epilogue to main ... This is due to the fact that gcc-8 generates more precise line info, making the instruction after the call to shr2 at 0x4008f1: ... 4008e4: 8b 05 aa 07 20 00 mov 0x2007aa(%rip),%eax # 601094 <g> 4008ea: 89 c7 mov %eax,%edi 4008ec: e8 1f fe ff ff callq 400710 <shr2@plt> 4008f1: 89 05 9d 07 20 00 mov %eax,0x20079d(%rip) # 601094 <g> ... a "recommended breakpoint location": ... [0x00000287] Special opcode 187: advance Address by 13 to 0x4008f1 and \ Line by 0 to 41 ... so when stepping out of shr2, gdb steps back onto line 41, the line containing the call to shr2. Fix this by detecting this situation and adding an extra step to reach line 42. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-06 Tom de Vries <tdevries@suse.de> * gdb.base/shlib-call.exp: Add extra step to reach shmain.c:42, if necessary.
2020-05-06[gdb/testsuite] Fix gdb_unbuffer_output return-typeTom de Vries2-1/+6
When running test-case gdb.base/shlib-call.exp with clang, we get: ... gdb compile failed, In file included from shmain.c:6: unbuffer_output.c:39:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ 1 warning generated. ... Fix this by changing the return-type to void. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-06 Tom de Vries <tdevries@suse.de> * lib/unbuffer_output.c (gdb_unbuffer_output): Change return type to void.
2020-05-06[gdb/testsuite] Fix gdb.base/consecutive.exp with gcc-8Tom de Vries4-13/+56
When running test-case gdb.base/consecutive.exp with gcc-8 instead of gcc-7, we get: ... (gdb) step^M ^M -Breakpoint 3, 0x00000000004004b1 in foo () at consecutive.c:10^M +Breakpoint 3, foo () at consecutive.c:10^M 10 return a[0] + a[1] + a[2] + a[3] + a[4] + a[5] + a[6];^M -(gdb) PASS: gdb.base/consecutive.exp: stopped at bp, 2nd instr +(gdb) FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr ... This is due to the fact that gcc-8 generates more precise line info, making the breakpoint address a "recommended breakpoint location", and consequently gdb doesn't print the address prefix anymore. Fix the FAIL by checking in the test-case whether the breakpoint address is at "recommended breakpoint location" or not. gdb/testsuite/ChangeLog: 2020-05-06 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (is_stmt_addresses, hex_in_list): New proc, factored out of ... * gdb.base/async.exp: ... here. * gdb.base/consecutive.exp: Handle if 2nd breakpoint is at a "recommended breakpoint location".
2020-05-06[gdb/testsuite] Compile compile-ifunc.c with -Wno-attribute-aliasTom de Vries2-2/+14
Consider the following test-case: ... $ cat 1.c typedef int (*final_t) (int arg); int final (int arg) { return arg + 1; } final_t gnu_ifunc (void) { return final; } int gnu_ifunc_alias (int) __attribute__ ((ifunc ("gnu_ifunc"))); int main (void) { return gnu_ifunc_alias (10); } ... with result: ... $ gcc 1.c $ ./a.out; echo $? 11 ... The test-case uses the ifunc attribute, but there's another solution using %gnu_indirect_function. Consider 2.c and 3.c: ... $ cat 2.c typedef int (*final_t) (int arg); int final (int arg) { return arg + 1; } asm (".type gnu_ifunc, %gnu_indirect_function"); final_t gnu_ifunc (void) { return final; } $ cat 3.c extern int gnu_ifunc (int); int main (void) { return gnu_ifunc (10); } ... However, it can be inconvenient to have seperate files for the incompatible decls of gnu_ifunc, so we can use this in a single file like this: ... $ cat 4.c typedef int (*final_t) (int arg); int final (int arg) { return arg + 1; } asm (".type gnu_ifunc, %gnu_indirect_function"); final_t gnu_ifunc (void) { return final; } extern int gnu_ifunc_alias (int arg) __attribute__ ((alias ("gnu_ifunc"))); int main (void) { return gnu_ifunc_alias (10); } ... This alias trick works ok at -O0, but not at -O2: ... $ gcc 4.c $ ./a.out; echo $? 11 $ gcc 4.c $ ./a.out; echo $? 176 ... and produces a warning with gcc-8 and later: ... $ gcc-8 4.c 4.c:7:12: warning: 'gnu_ifunc_alias' alias between functions of incompatible \ types 'int(int)' and 'int (*(void))(int)' [-Wattribute-alias] extern int gnu_ifunc_alias (int arg) __attribute__ ((alias ("gnu_ifunc"))); ^~~~~~~~~~~~~~~ 4.c:5:9: note: aliased declaration here final_t gnu_ifunc (void) ^~~~~~~~~ ... The warning is correct, but the mismatch is intentional. The last variant (%gnu_indirect_function + alias) is used in gdb.compile/compile-ifunc.c, so we run into the warning with recent gcc. Fix the warning by compiling with -Wno-attribute-alias. Tested the test-case on x86_64-linux with gcc-10, and observed I no longer see the warning: ... Running src/gdb/testsuite/gdb.compile/compile-ifunc.exp ... === gdb Summary === nr of untested testcases 1 ... gdb/testsuite/ChangeLog: 2020-05-06 Tom de Vries <tdevries@suse.de> * gdb.compile/compile-ifunc.exp: Use -Wno-attribute-alias.
2020-05-04[gdb/testsuite] Fix gdb.base/async.exp with gcc-8Tom de Vries2-6/+53
When running test-case gdb.base/async.exp with gcc-8, we run into: ... FAIL: gdb.base/async.exp: stepi& ... The problem is that with gcc-8, the instruction address is no longer printed: ... stepi& -(gdb) 0x00000000004004b2 9 x = 5; x = 5; x = 5; +(gdb) 9 x = 5; x = 5; x = 5; completed. -PASS: gdb.base/async.exp: stepi& +FAIL: gdb.base/async.exp: stepi& ... This is due to the fact that gcc-8 contains more precise line info, making the address being stepped to a "recommended breakpoint location", and consequently gdb doesn't print the address prefix anymore. Given that: - we step through statements on the same line, and - there's no addres prefix anymore, this gives the impression of lack of progress, which could be improved upon, filed as enhancement PR25911 - "Show column when stepping through line". Fix the FAIL by checking in the test-case whether addresses are at "recommended breakpoint location" or not. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-04 Tom de Vries <tdevries@suse.de> * gdb.base/async.exp: Check whether instruction addresses are a "recommended breakpoint location".
2020-05-03Update more calls to add_prefix_cmdTom Tromey4-9/+8
I looked at all the calls to add_prefix_cmd, and replaced them with calls to add_basic_prefix_cmd or add_show_prefix_cmd when appropriate. This makes gdb's command language a bit more regular. I don't think there's a significant downside. Note that this patch removes a couple of tests. The removed ones are completely redundant. gdb/ChangeLog 2020-05-03 Tom Tromey <tom@tromey.com> * breakpoint.c (catch_command, tcatch_command): Remove. (_initialize_breakpoint): Use add_basic_prefix_cmd, add_show_prefix_cmd. (set_breakpoint_cmd, show_breakpoint_cmd): Remove * utils.c (set_internal_problem_cmd, show_internal_problem_cmd): Remove. (add_internal_problem_command): Use add_basic_prefix_cmd, add_show_prefix_cmd. * mips-tdep.c (set_mipsfpu_command): Remove. (_initialize_mips_tdep): Use add_basic_prefix_cmd. * dwarf2/index-cache.c (set_index_cache_command): Remove. (_initialize_index_cache): Use add_basic_prefix_cmd. * memattr.c (dummy_cmd): Remove. (_initialize_mem): Use add_basic_prefix_cmd, add_show_prefix_cmd. * tui/tui-win.c (set_tui_cmd, show_tui_cmd): Remove. (_initialize_tui_win): Use add_basic_prefix_cmd, add_show_prefix_cmd. * cli/cli-logging.c (set_logging_command): Remove. (_initialize_cli_logging): Use add_basic_prefix_cmd, add_show_prefix_cmd. (show_logging_command): Remove. * target.c (target_command): Remove. (add_target): Use add_basic_prefix_cmd. gdb/testsuite/ChangeLog 2020-05-03 Tom Tromey <tom@tromey.com> * gdb.base/sepdebug.exp: Remove "catch" test. * gdb.base/break.exp: Remove "catch" test. * gdb.base/default.exp: Update expected output.
2020-05-02[gdb/testsuite] Fix i386-mpx.exp compilation warningsTom de Vries7-0/+41
When running test-case gdb.arch/i386-mpx.exp with gcc-10, we get: ... Running src/gdb/testsuite/gdb.arch/i386-mpx.exp ... gdb compile failed, xgcc: warning: switch '-mmpx' is no longer supported xgcc: warning: switch '-fcheck-pointer-bounds' is no longer supported ... The test-case uses a combination of options, -mmpx and -fcheck-pointer-bounds. The -fcheck-pointer-bounds option requires the -mmpx option: ... $ gcc -fcheck-pointer-bounds ~/hello.c hello.c:1:0: warning: Pointer Checker requires MPX support on this target. \ Use -mmpx options to enable MPX. #include <stdio.h> cc1: error: ‘-fcheck-pointer-bounds’ is not supported for this target ... Both options is no longer supported in gcc-9. Fix the warnings by testing if the option combination is supported. Tested on x86_64-linux, with gcc-7.5.0 and gcc-10.0.1. gdb/testsuite/ChangeLog: 2020-05-02 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (supports_mpx_check_pointer_bounds): New proc. * gdb.arch/i386-mpx-call.exp: Use supports_mpx_check_pointer_bounds. * gdb.arch/i386-mpx-map.exp: Same. * gdb.arch/i386-mpx-sigsegv.exp: Same. * gdb.arch/i386-mpx-simple_segv.exp: Same. * gdb.arch/i386-mpx.exp: Same.
2020-05-02[gdb/testsuite] Update psym-external-decl.exp for gcc-10/clangTom de Vries3-1/+10
When running test-case gdb.base/psym-external-decl.exp with gcc-10, we have: ... (gdb) print aaa^M 'aaa' has unknown type; cast it to its declared type^M (gdb) FAIL: gdb.base/psym-external-decl.exp: print aaa ... With an an earlier version, gcc still emits the debug info for the declaration of aaa: ... <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit) <d8> DW_AT_name : psym-external-decl.c <1><f4>: Abbrev Number: 2 (DW_TAG_variable) <f5> DW_AT_name : aaa <ff> DW_AT_external : 1 <ff> DW_AT_declaration : 1 ... but with gcc-10 that's no longer the case. Fix the test-case by adding a use of aaa in psym-external-decl.c. That still doesn't work for clang, so skip test in that case. Tested with x86_64-linux, with gcc 7.5.0, gcc 10.0.0 and clang 5.0.2. Also tested by reverting corresponding fix and ensuring test-case still fails. gdb/testsuite/ChangeLog: 2020-05-02 Tom de Vries <tdevries@suse.de> * gdb.base/psym-external-decl.c (main): Add use of variable aaa.
2020-05-01[gdb/testsuite] Fix gdb.ada/operator_bp.exp breakpoint location FAILsTom de Vries2-4/+15
When running test-case gdb.ada/operator_bp.exp with gcc-10, I run into: ... FAIL: gdb.ada/operator_bp.exp: break "+" FAIL: gdb.ada/operator_bp.exp: break "-" FAIL: gdb.ada/operator_bp.exp: break "<" FAIL: gdb.ada/operator_bp.exp: break "<=" FAIL: gdb.ada/operator_bp.exp: break ">" FAIL: gdb.ada/operator_bp.exp: break ">=" FAIL: gdb.ada/operator_bp.exp: break "=" FAIL: gdb.ada/operator_bp.exp: break "and" FAIL: gdb.ada/operator_bp.exp: break "or" FAIL: gdb.ada/operator_bp.exp: break "xor" FAIL: gdb.ada/operator_bp.exp: break "not" ... The first FAIL is because two breakpoint locations are expected, but there are more than 2: ... (gdb) break "+" Breakpoint 2 at 0x402c3c: "+". (6 locations) (gdb) info break Num Type Disp Enb Address What 2 breakpoint keep y <MULTIPLE> 2.1 y 0x0000000000402c3c in ops."+" at operator_bp/ops.adb:25 2.2 y 0x0000000000402e5b in ops."+" at operator_bp/ops.adb:119 2.3 y 0x0000000000414207 in system.storage_elements."+" at s-stoele.adb:82 2.4 y 0x0000000000414404 in system.storage_elements."+" at s-stoele.adb:87 2.5 y 0x0000000000414413 in system.storage_elements."+" at s-stoele.adb:87 2.6 y 0x0000000000414430 in system.storage_elements."+" at s-stoele.adb:81 ... This can be traced back to a extra debug info in the executable: ... $ readelf -w ops_test | grep system__storage_elements__Oadd <28104> DW_AT_name : system__storage_elements__Oadd__2 <2812e> DW_AT_name : system__storage_elements__Oadd ... Fix the FAILs by allowing more than the required amount of breakpoint locations. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-01 Tom de Vries <tdevries@suse.de> * gdb.ada/operator_bp.exp: Allow more than required amount of breakpoint.
2020-05-01[gdb/testsuite] Fix Wunused-result warning in until-reverse.cTom de Vries2-1/+6
When running test-case gdb.reverse/until-reverse.exp or gdb.reverse/until-precsave.exp with gcc-10, we run into a Wunused-result warning: ... gdb compile failed, gdb.reverse/until-reverse.c: In function 'main': gdb.reverse/until-reverse.c:40:14: warning: ignoring return value of \ 'malloc' declared with attribute 'warn_unused_result' [-Wunused-result] 40 | (void) malloc (1); | ^~~~~~~~~~ ... Fix this by using the result of malloc as argument to a free call. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-01 Tom de Vries <tdevries@suse.de> * gdb.reverse/until-reverse.c (main): Fix Wunused-result warning.
2020-04-30Calculate size of array of stubbed typeHannes Domani5-0/+106
Sizes of stubbed types are calculated on demand in check_typedef, so the same must also be done for arrays of stubbed types. A stubbed type is usually a structure that has only been forward declared, but can also happen if the structure has a virtual function that's not inline in the class definition. For these stubbed types, the size must be recalculated once the full definition is available. gdb/ChangeLog: 2020-04-30 Hannes Domani <ssbssa@yahoo.de> PR gdb/18706 * gdbtypes.c (check_typedef): Calculate size of array of stubbed type. gdb/testsuite/ChangeLog: 2020-04-30 Hannes Domani <ssbssa@yahoo.de> PR gdb/18706 * gdb.cp/stub-array-size.cc: New test. * gdb.cp/stub-array-size.exp: New file. * gdb.cp/stub-array-size.h: New test. * gdb.cp/stub-array-size2.cc: New test.
2020-04-30Adjust array pretty printer tests to the new formatHannes Domani2-3/+8
gdb/testsuite/ChangeLog: 2020-04-30 Hannes Domani <ssbssa@yahoo.de> * gdb.python/py-format-string.exp: Adjust pretty_arrays expected output to the new format.
2020-04-29gdb: fix duplicate test names in gdb.base/break.expSimon Marchi2-34/+43
These test names are duplicated: 2 PASS: gdb.base/break.exp: set breakpoint via non-integer convenience variable disallowed 2 PASS: gdb.base/break.exp: set convenience variable $foo to 81.5 Wrap them with `with_test_prefix`. I've actually wrapped a bit more tests that are related, I think it helps to give the test names a bit more context. The modified test names are: -PASS: gdb.base/break.exp: set convenience variable $foo to bp_location11 -PASS: gdb.base/break.exp: set breakpoint via convenience variable -PASS: gdb.base/break.exp: set convenience variable $foo to 81.5 -PASS: gdb.base/break.exp: set breakpoint via non-integer convenience variable disallowed +PASS: gdb.base/break.exp: set line breakpoint via convenience variable: set convenience variable $foo to bp_location11 +PASS: gdb.base/break.exp: set line breakpoint via convenience variable: break $foo +PASS: gdb.base/break.exp: set line breakpoint via convenience variable: set convenience variable $foo to 81.5 +PASS: gdb.base/break.exp: set line breakpoint via convenience variable: non-integer convenience variable disallowed -PASS: gdb.base/break.exp: set $l = 47 -PASS: gdb.base/break.exp: break break.c:$l -PASS: gdb.base/break.exp: set convenience variable $foo to 81.5 -PASS: gdb.base/break.exp: set breakpoint via non-integer convenience variable disallowed +PASS: gdb.base/break.exp: set line:file breakpoint via convenience variable: set $l = 47 +PASS: gdb.base/break.exp: set line:file breakpoint via convenience variable: break break.c:$l +PASS: gdb.base/break.exp: set line:file breakpoint via convenience variable: set convenience variable $foo to 81.5 +PASS: gdb.base/break.exp: set line:file breakpoint via convenience variable: non-integer convenience variable disallowed gdb/testsuite/ChangeLog: * gdb.base/break.exp: Use with_test_prefix.
2020-04-29[gdb/testsuite] Add xfails for PR gcc/90232Tom de Vries4-3/+57
With target board debug-types, we have these FAILs: ... FAIL: gdb.guile/scm-symtab.exp: test simple_struct in static symbols FAIL: gdb.python/py-symtab.exp: test simple_struct in static symbols ... due to PR gcc/90232, as explained in commit 15cd93d05e8 "[gdb/symtab] Handle struct decl with DW_AT_signature". Marks these as XFAILs. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-29 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (debug_types): New proc. * gdb.guile/scm-symtab.exp: Add xfail for PR gcc/90232. * gdb.python/py-symtab.exp: Same.
2020-04-29Fix array pretty formatterHannes Domani3-0/+95
Currently, printing with array pretty formatting makes the output actually less readable than without: (gdb) p -array on -- {{1,2,3},{4,5,6}} $1 = { {1, 2, 3}, {4, 5, 6}} (gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}} $2 = {[0] = {[0] = 1, [1] = 2, [2] = 3}, [1] = {[0] = 4, [1] = 5, [2] = 6}} These changes now also put the first element and the array end bracket on a new line, similar to the structure pretty formatter: (gdb) p -array on -- {{1,2,3},{4,5,6}} $1 = { { 1, 2, 3 }, { 4, 5, 6 } } (gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}} $2 = { [0] = { [0] = 1, [1] = 2, [2] = 3 }, [1] = { [0] = 4, [1] = 5, [2] = 6 } } gdb/ChangeLog: 2020-04-29 Hannes Domani <ssbssa@yahoo.de> PR gdb/17320 * ada-valprint.c (val_print_packed_array_elements): Move array end bracket to new line. (ada_val_print_string): Remove extra spaces before first array element. * c-valprint.c (c_value_print_array): Likewise. * m2-valprint.c (m2_print_array_contents): Likewise. (m2_value_print_inner): Likewise. * p-valprint.c (pascal_value_print_inner): Likewise. * valprint.c (generic_val_print_array): Likewise. (value_print_array_elements): Move first array element and array end bracket to new line. gdb/testsuite/ChangeLog: 2020-04-29 Hannes Domani <ssbssa@yahoo.de> PR gdb/17320 * gdb.base/pretty-array.c: New test. * gdb.base/pretty-array.exp: New file.
2020-04-29[gdb] Fix range loop index in find_methodTom de Vries3-2/+39
With target board debug-types, we have: ... FAIL: gdb.cp/cpexprs.exp: list policy1::function ... This is a regression triggered by commit 770479f223e "gdb: Fix toplevel types with -fdebug-types-section". However, the FAIL is caused by commit 4dedf84da98 "Change decode_compound_collector to use std::vector" which changes a VEC_iterate loop into a range loop: ... - for (ix = 0; VEC_iterate (symbolp, sym_classes, ix, sym); ++ix) + unsigned int ix = 0; + for (const auto &sym : *sym_classes) ... but fails to ensure that the increment of ix happens every iteration. Fix this by calculating the index variable at the start of the loop body: ... for (const auto &elt : *sym_classes) { unsigned int ix = &elt - &*sym_classes->begin (); ... Tested on x86_64-linux, with native and target board debug-types. gdb/ChangeLog: 2020-04-29 Tom de Vries <tdevries@suse.de> PR symtab/25889 * linespec.c (find_method): Fix ix calculation. gdb/testsuite/ChangeLog: 2020-04-29 Tom de Vries <tdevries@suse.de> PR symtab/25889 * gdb.cp/cpexprs.exp: Adapt for inclusion. * gdb.cp/cpexprs-debug-types.exp: New file. Set -fdebug-types-section and include cpexprs.exp.
2020-04-28Add missing ChangeLog entriesTom de Vries1-0/+6
2020-04-28gdb: Fix toplevel types with -fdebug-types-sectionMark Williams2-0/+57
When debugging a program compiled with -fdebug-types-section, only the first top-level type in each file is visible to gdb. The problem was caused by moving the assignment to list_in_scope from process_full_comp_unit and process_full_type_unit to start_symtab. This was fine for process_full_comp_unit, because symtabs and comp units are one-to-one. But there can be many type units per symtab (one for each type), and we only call start_symtab for the first one. This adds the necessary assignments on the paths where start_symtab is not called. gdb/Changelog: 2020-04-28 Mark Williams <mark@myosotissp.com> PR gdb/24480 * dwarf2read.c: Add missing assingments to list_in_scope when start_symtab was already called. gdb/testsuite/Changelog: 2020-04-28 Mark Williams <mark@myosotissp.com> PR gdb/24480 * dw4-toplevel-types.exp: Test for top level types. * dw4-toplevel-types.cc: Test for top level types.
2020-04-28Fix typo (thead -> thread)Tankut Baris Aktemur2-1/+6
gdb/stubs/ChangeLog: 2020-04-28 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * ia64vms-stub.c: Fix typo in comment (thead -> thread). gdb/testsuite/ChangeLog: 2020-04-28 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.threads/stop-with-handle.exp: Fix typo in comment (theads -> threads). gdbsupport/ChangeLog: 2020-04-28 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb-sigmask.h: Fix typo (pthead_sigmask -> pthread_sigmask).
2020-04-28[gdb/testsuite] Add PR number to KFAIL in gdb.opt/inline-cmds.expTom de Vries2-1/+5
With test-case gdb.opt/inline-cmds.exp, we have: ... KFAIL: gdb.opt/inline-cmds.exp: next to second func1 (PRMS: gdb/NNNN) ... I've filed PR25884 for this failure. Set the KFAIL PR accordingly. gdb/testsuite/ChangeLog: 2020-04-28 Tom de Vries <tdevries@suse.de> * gdb.opt/inline-cmds.exp: Set KFAIL PR.
2020-04-28[gdb/testsuite] Remove KFAIL from gdb.base/info-macros.expTom de Vries2-4/+5
When running test-case gdb.base/info-macros.exp, we have: ... (gdb) KFAIL: gdb.base/info-macros.exp: info macros info-macros.c:42 \ (PRMS: gdb/NNNN) ... The described failure mode however: ... set test "info macros info-macros.c:42" set r1 ".*define DEF_MACROS" set r2 ".*define ONE" setup_kfail "gdb/NNNN" *-*-* gdb_test "$test" "$r1$r2" ... does not match the actual output, given that both defines are in fact printed. The pattern fails to match because it's missing a trailing ".*". Fix this by removing the KFAIL and adding the missing trailing ".*". Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-28 Tom de Vries <tdevries@suse.de> * gdb.base/info-macros.exp: Remove KFAIL. Add missing trailing ".*".
2020-04-28[gdb/testsuite] Add PR number in KFAIL in gdb.ada/array_ptr_renaming.expTom de Vries2-1/+5
When running test-case gdb.ada/array_ptr_renaming.exp we run into: ... (gdb) print ntp^M $3 = (3 => 30, 40)^M (gdb) KFAIL: gdb.ada/array_ptr_renaming.exp: print ntp (PRMS: gdb/NNNN) ... I've opened PR25883 for this failure. Reference the PR from the KFAIL, such that we have: ... KFAIL: gdb.ada/array_ptr_renaming.exp: print ntp (PRMS: gdb/25883) ... gdb/testsuite/ChangeLog: 2020-04-28 Tom de Vries <tdevries@suse.de> * gdb.ada/array_ptr_renaming.exp: Add PR number in KFAIL.
2020-04-28[gdb/symtab] Handle struct decl with DW_AT_signatureTom de Vries3-0/+180
Consider a test-case with sources 36.c: ... struct s { int i; }; extern void f (void); int main (void) { struct s a; f (); return 0; } ... and 36b.c: ... struct s { int j; }; void f (void) { struct s b; } ... compiled like this: ... $ gcc 36.c 36b.c -g ... It contains DWARF like this: ... <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit) <d8> DW_AT_name : 36.c <1><f4>: Abbrev Number: 2 (DW_TAG_structure_type) <f5> DW_AT_name : s <2><fe>: Abbrev Number: 3 (DW_TAG_member) <ff> DW_AT_name : i <1><110>: Abbrev Number: 5 (DW_TAG_subprogram) <111> DW_AT_name : main <2><12d>: Abbrev Number: 6 (DW_TAG_variable) <12e> DW_AT_name : a <132> DW_AT_type : <0xf4> <0><146>: Abbrev Number: 1 (DW_TAG_compile_unit) <14c> DW_AT_name : 36b.c <1><168>: Abbrev Number: 2 (DW_TAG_structure_type) <169> DW_AT_name : s <2><172>: Abbrev Number: 3 (DW_TAG_member) <173> DW_AT_name : j <1><184>: Abbrev Number: 5 (DW_TAG_subprogram) <185> DW_AT_name : f <2><19b>: Abbrev Number: 6 (DW_TAG_variable) <19c> DW_AT_name : b <1a0> DW_AT_type : <0x168> ... And when printing "struct s", we get first a random one (with int j), and then context-specific ones (with int i in main, and int j in f): ... $ gdb -batch a.out \ -ex "ptype struct s" \ -ex start \ -ex "ptype struct s" \ -ex "break f" -ex continue \ -ex "ptype struct s" \ | grep "int [ij];" int j; int i; int j; ... Same for -readnow. However, if we use -fdebug-types-section: ... $ gcc 36.c 36b.c -g -fdebug-types-section ... we get: ... $ gdb ... | grep "int [ij];" int j; int i; int i; $ gdb -readnow ... | grep "int [ij];" int j; int j; int j; ... This is due to the fact that both "struct s" DIEs have been moved to the .debug_types section: ... Compilation Unit @ offset 0x0: Signature: 0xfd1462823bb6f7b7 <0><17>: Abbrev Number: 1 (DW_TAG_type_unit) <1><1d>: Abbrev Number: 2 (DW_TAG_structure_type) <1e> DW_AT_name : s <2><27>: Abbrev Number: 3 (DW_TAG_member) <28> DW_AT_name : i Compilation Unit @ offset 0x3a: Signature: 0x534310fbefba324d <0><51>: Abbrev Number: 1 (DW_TAG_type_unit) <1><57>: Abbrev Number: 2 (DW_TAG_structure_type) <58> DW_AT_name : s <2><61>: Abbrev Number: 3 (DW_TAG_member) <62> DW_AT_name : j ... and there's no longer a "struct s" DIE in the 36.c and and 36b.c CUs to specify which "struct s" belongs in the CU. This is gcc PR90232. However, using a tentative patch for gcc that adds these DIEs (according to DWARF standard: If the complete declaration of a type has been placed in a separate type unit, an incomplete declaration of that type in the compilation unit may provide the unique 64-bit signature of the type using a DW_AT_signature attribute): ... <0><d2>: Abbrev Number: 5 (DW_TAG_compile_unit) <d8> DW_AT_name : 36.c + <1><f4>: Abbrev Number: 6 (DW_TAG_structure_type) + <f5> DW_AT_name : s + <f7> DW_AT_signature : signature: 0xfd1462823bb6f7b7 + <ff> DW_AT_declaration : 1 <0><13c>: Abbrev Number: 5 (DW_TAG_compile_unit) <142> DW_AT_name : 36b.c + <1><15e>: Abbrev Number: 6 (DW_TAG_structure_type) + <15f> DW_AT_name : s + <161> DW_AT_signature : signature: 0x534310fbefba324d + <169> DW_AT_declaration : 1 ... still does not help, because they're declarations, so new_symbol is not called for them in process_structure_scope. Fix this by calling new_symbol for these decls. Build and tested on x86_64-linux. Also tested with target board enabling by default -fdebug-types-section -gdwarf-4, and with gcc with aforementioned tentative patch. In this configuration, the patch reduces number of FAILs from 2888 to 238. gdb/ChangeLog: 2020-04-28 Tom de Vries <tdevries@suse.de> * dwarf2/read.c (process_structure_scope): Add symbol for struct decl with DW_AT_signature. gdb/testsuite/ChangeLog: 2020-04-28 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/main-foo.c: New test. * gdb.dwarf2/struct-with-sig.exp: New file.
generated by cgit v1.1 at 2024-11-20 16:28:47 +0000