aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2020-03-19gdb: Remove C++ symbol aliases from completion listAndrew Burgess3-0/+132
Consider debugging the following C++ program: struct object { int a; }; typedef object *object_p; static int get_value (object_p obj) { return obj->a; } int main () { object obj; obj.a = 0; return get_value (&obj); } Now in a GDB session: (gdb) complete break get_value break get_value(object*) break get_value(object_p) Or: (gdb) break get_va<TAB> (gdb) break get_value(object<RETURN> Function "get_value(object" not defined. Make breakpoint pending on future shared library load? (y or [n]) n The reason this happens is that we add completions based on the msymbol names and on the symbol names. For C++ both of these names include the parameter list, however, the msymbol names have some differences from the symbol names, for example: + typedefs are resolved, + whitespace rules are different around pointers, + the 'const' keyword is placed differently. What this means is that the msymbol names and symbol names appear to be completely different to GDB's completion tracker, and therefore to readline when it offers the completions. This commit builds on the previous commit which reworked the completion_tracker class. It is now trivial to add a remove_completion member function, this is then used along with cp_canonicalize_string_no_typedefs to remove the msymbol aliases from the completion tracker as we add the symbol names. Now, for the above program GDB only presents a single completion for 'get_value', which is 'get_value(object_p)'. It is still possible to reference the symbol using the msymbol name, so a user can manually type out 'break get_value (object *)' if they wish and will get the expected behaviour. I did consider adding an option to make this alias exclusion optional, in the end I didn't bother as I didn't think it would be very useful, but I can easily add such an option if people think it would be useful. gdb/ChangeLog: * completer.c (completion_tracker::remove_completion): Define new function. * completer.h (completion_tracker::remove_completion): Declare new function. * symtab.c (completion_list_add_symbol): Remove aliasing msymbols when adding a C++ function symbol. gdb/testsuite/ChangeLog: * gdb.linespec/cp-completion-aliases.cc: New file. * gdb.linespec/cp-completion-aliases.exp: New file. Change-Id: Ie5c7c9fc8ecf973072cfb4a9650867104bf7f50c
2020-03-19[gdb/testsuite] Fix gdb.opt/inline-locals.exp KFAILsTom de Vries2-4/+27
When running test-case gdb.opt/inline-locals.exp, I get: ... Running src/gdb/testsuite/gdb.opt/inline-locals.exp ... KPASS: gdb.opt/inline-locals.exp: info locals above bar 2 (PRMS gdb/xyz) KPASS: gdb.opt/inline-locals.exp: info locals above bar 3 (PRMS gdb/xyz) ... I've opened PR25695 - 'abstract and concrete variable listed both with "info locals"' to refer to in the PRMS field, and this patch adds that reference. Furthermore, I noticed that while I see KPASSes, given the problem description the tests should actually be KFAILs. This patch also fixes that. Tested on x86_64-linux. With gcc 7.5.0, I get 2 KFAILs. With clang 5.0.2, the tests pass. gdb/testsuite/ChangeLog: 2020-03-19 Tom de Vries <tdevries@suse.de> * gdb.opt/inline-locals.exp: Add kfail PR number. Make kfail matching more precise.
2020-03-18[gdb/testsuite] Add test-case gdb.dwarf2/break-inline-psymtab.expTom de Vries4-0/+99
Add a test-case that tests whether we can set a breakpoint on an inlined inline function in CU for which the partial symtab has not yet been expanded. Tested on x86_64-linux, with gcc 4.8.5, gcc-7.5.0, gcc-10.0.1, and clang 5.0.2. gdb/testsuite/ChangeLog: 2020-03-18 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/break-inline-psymtab-2.c: New test. * gdb.dwarf2/break-inline-psymtab.c: New test. * gdb.dwarf2/break-inline-psymtab.exp: New file.
2020-03-17[gdb/testsuite] Give up after consecutive timeouts in completion-support.expTom de Vries1-2/+25
When running test-case gdb.linespec/cpcompletion.exp with target board unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into lots of timeouts, in particular with this pattern: ... FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \ cmd complete "b template2_" FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \ tab complete "b template2_st" (timeout) FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \ cmd complete "b template2_st" FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \ tab complete "b template2_str" (timeout) FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \ cmd complete "b template2_str" FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \ tab complete "b template2_stru" (timeout) ... Fix this by detecting timeouts in test_complete_prefix_range_re and giving up after 3 consecutive timeouts. This reduces testing time from ~39m to ~9m. Tested on x86_64-linux.
2020-03-16[gdb/testsuite] Add cache_verify option for gdb_caching_procsTom de Vries2-5/+37
Test-case gdb.base/gdb-caching-proc.exp tests whether procs declared using gdb_caching_proc give the same results when called more than once. While this tests consistency of the procs in the context of that test-case, it doesn't test consistency across the call sites. Add a local variable cache_verify to proc gdb_do_cache, that can be set to 1 to verify gdb_caching_proc consistency across the call sites. Likewise, add a local variable cache_verify_proc to set to the name of the gdb_caching_proc to verify. This can f.i. be used when changing an existing proc into a gdb_caching_proc. Tested on x86_64-linux, with cache_verify set to both 0 and 1. gdb/testsuite/ChangeLog: 2020-03-16 Tom de Vries <tdevries@suse.de> * lib/cache.exp (gdb_do_cache): Add and handle local variables cache_verify and cache_verify_proc.
2020-03-15[gdb/testsuite] Fix solib-list.exp test-case for exec with debug-infoTom de Vries2-2/+20
Since commit a2fedca99c "Implement 'set/show exec-file-mismatch'.", I see the following regression on openSUSE Leap 15.1: ... FAIL: gdb.server/solib-list.exp: non-stop 0: target remote \ (got interactive prompt) FAIL: gdb.server/solib-list.exp: non-stop 1: target remote \ (got interactive prompt) ... The first FAIL in more detail: ... (gdb) PASS: gdb.server/solib-list.exp: non-stop 0: file binfile target remote localhost:2346 Remote debugging using localhost:2346 warning: Mismatch between current exec-file /data/gdb_versions/devel/build/\ gdb/testsuite/outputs/gdb.server/solib-list/solib-list and automatically determined exec-file /lib64/ld-2.26.so exec-file-mismatch handling is currently "ask" Load new symbol table from "/lib64/ld-2.26.so"? (y or n) n warning: loading /lib64/ld-2.26.so Not confirmed. Reading /lib64/ld-linux-x86-64.so.2 from remote target... warning: File transfers from remote targets can be slow. \ Use "set sysroot" to access files locally instead. Reading /lib64/ld-linux-x86-64.so.2 from remote target... Reading symbols from target:/lib64/ld-linux-x86-64.so.2... Reading /lib64/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target... Reading /lib64/.debug/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote \ target... Reading /data/gdb_versions/devel/install/lib64/debug//lib64/\ ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target... Reading /data/gdb_versions/devel/install/lib64/debug/lib64/\ /ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target... Reading target:/data/gdb_versions/devel/install/lib64/debug/lib64/\ /ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target... (No debugging symbols found in target:/lib64/ld-linux-x86-64.so.2) 0x00007ffff7dd7ea0 in ?? () (gdb) FAIL: gdb.server/solib-list.exp: non-stop 0: target remote (got \ interactive prompt) ... The commit introduces the "Load new symbol table from" question, and gdb_test_multiple defaults to answering "no" and reporting the "got interactive prompt" FAIL. This FAIL is not seen on f.i. debian 10.2. The difference originates from the fact that the solib-list executable has debug-info in the openSUSE case, while it doesn't in the debian case. We can prevent the failure on openSUSE by stripping the executable from debug-info: ... + exec strip --strip-debug ${binfile} ... The difference in behaviour is a bug or improvement opportunity in the exec-file-mismatch, filed as PR25475. This patch fixes the FAIL by handling the question in the test-case. Tested on x86_64-linux. Tested on x86_64-linux with the gdbserver part of the patch introducing the test-case reverted to ensure that this still FAILs. gdb/testsuite/ChangeLog: 2020-03-15 Tom de Vries <tdevries@suse.de> * gdb.server/solib-list.exp: Handle 'Load new symbol table from "/lib64/ld-2.26.so"? (y or n)'.
2020-03-15[gdb/testsuite] Fix check-read1 FAIL with gdb.base/maint.expTom de Vries2-26/+24
When running test-case gdb.base/maint.exp with check-read1, I run into: ... FAIL: gdb.base/maint.exp: (timeout) maint print objfiles ... The FAIL happens because command output contains long lines like this: ... file1 at $hex, file2 at $hex, ..., $file$n at $hex, ... F.i., such a line for libc.so.debug contains 82000 chars. Fix this this by reading long lines bit by bit. Also, replace the testing of the command output formulated using a gdb_send combined with gdb_expect-in-a-loop, with a regular gdb_test_multiple with exp_continue. Tested on x86_64-linux, with make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-15 Tom de Vries <tdevries@suse.de> * gdb.base/maint.exp: Use exp_continue in long lines for "maint print objfiles".
2020-03-14Add C parser support for "restrict" and "_Atomic"Tom Tromey2-0/+15
A user noticed that "watch -location" would fail with a "restrict" pointer. The issue here is that if the DWARF mentions "restrict", gdb will put this into the type name -- but then the C parser will not be able to parse this type. This patch adds support for "restrict" and "_Atomic" to the C parser. C++ doesn't have "restrict", but does have some GCC extensions. The type printer is changed to handle this difference as well, so that watch expressions will work properly. gdb/ChangeLog 2020-03-14 Tom Tromey <tom@tromey.com> * c-typeprint.c (cp_type_print_method_args): Print "__restrict__" for C++. (c_type_print_modifier): Likewise. Add "language" parameter. (c_type_print_varspec_prefix, c_type_print_base_struct_union) (c_type_print_base_1): Update. * type-stack.h (enum type_pieces) <tp_atomic, tp_restrict>: New constants. * type-stack.c (type_stack::insert): Handle tp_atomic and tp_restrict. (type_stack::follow_type_instance_flags): Likewise. (type_stack::follow_types): Likewise. Merge type-following code. * c-exp.y (RESTRICT, ATOMIC): New tokens. (space_identifier, cv_with_space_id) (const_or_volatile_or_space_identifier_noopt) (const_or_volatile_or_space_identifier): Remove. (single_qualifier, qualifier_seq_noopt, qualifier_seq): New rules. (ptr_operator, typebase): Update. (enum token_flag) <FLAG_C>: New constant. (ident_tokens): Add "restrict", "__restrict__", "__restrict", and "_Atomic". (lex_one_token): Handle FLAG_C. gdb/testsuite/ChangeLog 2020-03-14 Tom Tromey <tom@tromey.com> * gdb.base/cvexpr.exp: Add test for _Atomic and restrict.
2020-03-14[gdb/testsuite] Fix check-read1 FAILs in mi-fortran-modules.expTom de Vries2-17/+103
When running test-case gdb.mi/mi-fortran-modules.exp with check-read1, I run into: ... FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions (timeout) FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions \ --name _all (unexpected output) FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions \ --module mod[123] (unexpected output) FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-variables \ (unexpected output) ... Fix this by using exp_continue. Tested on x86_64, using make target check and check-read1. gdb/testsuite/ChangeLog: 2020-03-14 Tom de Vries <tdevries@suse.de> * gdb.mi/mi-fortran-modules.exp: Use exp_continue.
2020-03-14[gdb/testsuite] Fix check-read1 FAIL in attach-many-short-lived-threads.expTom de Vries2-5/+16
When running test-case gdb.threads/attach-many-short-lived-threads.exp with check-read1, I ran into: ... FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: \ no new threads (timeout) ... Fix this by rewriting the gdb_test_multiple call using -lbl and exp_continue. Tested on x86_64-linux, with make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-14 Tom de Vries <tdevries@suse.de> * gdb.threads/attach-many-short-lived-threads.exp: Read "info threads" result in line-by-line fashion.
2020-03-14[gdb/testsuite] Fix unrecognized debug output level 'statement-frontiers' ↵Tom de Vries3-0/+20
message When running testcase gdb.cp/step-and-next-inline.exp, I get: ... Running src/gdb/testsuite/gdb.cp/step-and-next-inline.exp ... gdb compile failed, g++: error: unrecognized debug output level \ 'statement-frontiers' gdb compile failed, g++: error: unrecognized debug output level \ 'statement-frontiers' === gdb Summary === # of untested testcases 2 ... Fix this by using a new gdb_caching_proc supports_statement_frontiers. Tested on x86_64-linux, with gcc 7.5.0 (which does not support -gstatement-frontiers) and with gcc 8.4.0 (which does support -gstatement-frontiers). gdb/testsuite/ChangeLog: 2020-03-14 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (supports_statement_frontiers): New proc. * gdb.cp/step-and-next-inline.exp: Use supports_statement_frontiers.
2020-03-14[gdb/testsuite] Fix FAIL in gdb.base/printcmds.expTom de Vries2-1/+6
With test-case gdb.base/printcmds.exp, I run into: ... (gdb) print teststring2^M $563 = (charptr) "more contents"^M (gdb) FAIL: gdb.base/printcmds.exp: print teststring2 ... The corresponding test is: ... gdb_test "print teststring2" " = (charptr) \"more contents\"" ... Fix the FAIL by adding the missing quoting for the parentheses around charptr. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-14 Tom de Vries <tdevries@suse.de> * gdb.base/printcmds.exp: Add missing quoting for "print teststring2".
2020-03-13Use common_val_print in c-valprint.cTom Tromey3-0/+13
This changes c_value_print to call common_val_print. This is more complicated than the usual sort of common_val_print change, due to the handling of RTTI. gdb/ChangeLog 2020-03-13 Tom Tromey <tom@tromey.com> * c-valprint.c (c_value_print): Use common_val_print. gdb/testsuite/ChangeLog 2020-03-13 Tom Tromey <tom@tromey.com> * gdb.base/printcmds.exp (test_print_strings): Add regression test. * gdb.base/printcmds.c (charptr): New typedef. (teststring2): New global.
2020-03-13gdb/testsuite: Remove paths and make test names uniqueAndrew Burgess2-7/+18
Removes paths from some test names, and make the test names unique in the gdb.base/break-interp.exp test file. gdb/testsuite/ChangeLog: * gdb.base/break-interp.exp: Use the tail of the filename, not the full path in the test name. (test_ld): Add some with_test_prefix blocks to make test names unique.
2020-03-13[gdb/testsuite] Fix buffer full errors in gdb.mi/mi-sym-info.expTom de Vries2-25/+148
With debug info packages for system libs installed, I run into buffer full errors with test-case gdb.mi/mi-sym-info.exp. Fix these using exp_continue. This exposes timeouts due to gdb taking a long time before starting to print output. Fix these using with_timeout_factor. Tested on x86_64-linux, with make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-13 Tom de Vries <tdevries@suse.de> * gdb.mi/mi-sym-info.exp: Fix buffer full errors, and timeouts.
2020-03-13[gdb/testsuite] Fix mi-sym-info.exp matching FAILs (2)Tom de Vries2-5/+9
With debug info packages for system libraries installed, I currently run into some "internal buffer is full" errors with test-case gdb.mi/mi-sym-info.exp, but if I disable the corresponding tests, I get further-on: ... FAIL: gdb.mi/mi-sym-info.exp: List all functions matching pattern f3 \ (unexpected output) FAIL: gdb.mi/mi-sym-info.exp: List all functions matching type void \ (unexpected output) FAIL: gdb.mi/mi-sym-info.exp: List all variables matching type float \ (unexpected output) FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \ (unexpected output) FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 2 \ (unexpected output) ... Fix this by making the matching more precise. Tested on x86_64-linux. Also tested with an extra: ... mi_gdb_test "set debug-file-directory" ... to prevent gdb from finding the debug info for system libraries. gdb/testsuite/ChangeLog: 2020-03-13 Tom de Vries <tdevries@suse.de> * gdb.mi/mi-sym-info.exp: Make matching more precise.
2020-03-13[gdb/symtab] Fix partial unit psymtabsTom de Vries2-0/+18
Consider test-case gdb.dwarf2/imported-unit.exp. It contains a CU with type int: ... <0><129>: Abbrev Number: 2 (DW_TAG_compile_unit) <12a> DW_AT_language : 4 (C++) <12b> DW_AT_name : imported_unit.c <1><13b>: Abbrev Number: 3 (DW_TAG_base_type) <13c> DW_AT_byte_size : 4 <13d> DW_AT_encoding : 5 (signed) <13e> DW_AT_name : int ... which is imported in another CU: ... <0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit) <d3> DW_AT_language : 4 (C++) <d4> DW_AT_name : <artificial> <1><e1>: Abbrev Number: 3 (DW_TAG_imported_unit) <e2> DW_AT_import : <0x129> [Abbrev Number: 2] ... However, if we print the partial symbols: ... $ gdb -batch imported-unit -ex "maint print psymbols" ... we see type int both in the importing CU: ... Partial symtab for source file <artificial>@0xc7 (object 0x29f9b80) ... Depends on 1 other partial symtabs. 0 0x2a24240 imported_unit.c Global partial symbols: `main', function, 0x4004b2 Static partial symbols: `int', type, 0x0 ... and in the imported CU: ... Partial symtab for source file imported_unit.c (object 0x2a24240) ... Depends on 0 other partial symtabs. Shared partial symtab with user 0x29f9b80 Static partial symbols: `int', type, 0x0 ... This is an artefact resulting from the fact that all CUs in an objfile share the same storage array for static partial symbols (and another array for global partial symbols), using a range to describe their symbols. Then when scanning the partial symbols of a CU and encountering an import, either: - the referred CU has not been parsed yet, and will be parsed, and the range of static partial symbols of the referred CU will be a subrange of the range of static partial symbols of this CU, or - the referred CU has already been parsed, and the range of static partial symbols of the referred CU will not be a subrange of the range of static partial symbols of this CU. This is inconsistent handling, and confuses the notion of a symbol belonging to a single symtab. Furthermore, it might slow down searches, given that the symbol needs to be skipped twice. Finally, the same issue holds for global partial symbols, where the range of a CU is sorted after parsing is finished. Obviously sorting the range of a CU may invalidate subranges, effectively moving symbols in and out of imported CUs. Fix this for both static and global partial symbols, by gathering partial symbols in a per-CU vector, and adding those symbols to the per-objfile storage only once complete. Tested on x86_64-linux, with native and board cc-with-dwz and cc-with-dwz-m. gdb/ChangeLog: 2020-03-13 Tom de Vries <tdevries@suse.de> PR symtab/25646 * psymtab.c (partial_symtab::partial_symtab): Don't set globals_offset and statics_offset. Push element onto current_global_psymbols and current_static_psymbols stacks. (concat): New function. (end_psymtab_common): Set globals_offset and statics_offset. Pop element from current_global_psymbols and current_static_psymbols stacks. Concat popped elements to global_psymbols and static_symbols. (add_psymbol_to_list): Use current_global_psymbols and current_static_psymbols stacks. * psymtab.h (class psymtab_storage): Add current_global_psymbols and current_static_psymbols fields. gdb/testsuite/ChangeLog: 2020-03-13 Tom de Vries <tdevries@suse.de> PR symtab/25646 * gdb.dwarf2/imported-unit.exp: Add test.
2020-03-13[gdb/testsuite] Fix mi-sym-info.exp matching FAILsTom de Vries3-5/+20
When running gdb.mi/mi-sym-info.exp on openSUSE Leap 15.1, I get: ... FAIL: gdb.mi/mi-sym-info.exp: List all functions matching type void \ (unexpected output) FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-variables --max-results 3 \ (unexpected output) FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-types --max-results 4 \ (unexpected output) ... The executable contains debug info from files other than the source files: ... $ readelf -wi mi-sym-info | grep "DW_AT_name.*\.[cS]$" | awk '{print $8}' ../sysdeps/x86_64/start.S init.c ../sysdeps/x86_64/crti.S src/gdb/testsuite/gdb.mi/mi-sym-info-1.c src/gdb/testsuite/gdb.mi/mi-sym-info-2.c elf-init.c ../sysdeps/x86_64/crtn.S ... The test does not expect this extra info, resulting in matching failures. Fix this by restricting the failing commands using --name. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-13 Tom de Vries <tdevries@suse.de> * gdb.mi/mi-sym-info-2.c (another_char_t, another_short_t): New typedef. (var1, var2): New variable. * gdb.mi/mi-sym-info.exp: Add --name to various commands to restrict matching symbols.
2020-03-13[gdb/testsuite] Fix check-read1 FAIL in gdb.tui/corefile-run.expTom de Vries4-4/+24
With test-case gdb.tui/corefile-run.exp and make target check-read1, I run into: ... FAIL: gdb.tui/corefile-run.exp: run until the end ... In more detail, using -v: ... PASS: gdb.tui/corefile-run.exp: load corefile ^M+++ _ctl_0x0d ^[[17d+++ _csi_d <<<17>>> ^[[M+++ _csi_M <<<>>> ^[[24d+++ _csi_d <<<24>>> (INSERT <<(>> gINSERT <<g>> dINSERT <<d>> bINSERT <<b>> )INSERT <<)>> INSERT << >> FAIL: gdb.tui/corefile-run.exp: run until the end ... With some debugging code added in wait_for, what happens becomes more clear: ... if {[regexp -- $wait_for $prev]} { + verbose -log "\nwait_for: MATCHED line ($_cur_y): \"$prev\"" + verbose -log "wait_for: AGAINST regexp: \"$wait_for\"" ... In corefile-run.exp, we execute: ... Term::command "run" ... and in proc Term::command, we send the command, and then call wait_for: ... proc command {cmd} { send_gdb "$cmd\n" wait_for [string_to_regexp $cmd] } ... which first waits for the command string, and then for the prompt. In this case however, the matching of the command string triggers on a previous line: ... wait_for: MATCHED line (16): \ "(gdb) core-file corefile-run.core[New LWP 6426] <lots-of-spaces>" wait_for: AGAINST regexp: "run" ... and from there on things go out of sync, eventually resulting in the FAIL. Fix this in proc command by more precisely specifying the expected pattern: adding a ^$gdb_prompt prefix. Add a command_no_prompt_prefix variant to use for initial terminal commands where there's no prompt yet. Tested gdb.tui/*.exp on x86_64-linux, with make target check and check-read1. gdb/testsuite/ChangeLog: 2020-03-13 Tom de Vries <tdevries@suse.de> * lib/tuiterm.exp (Term::command_no_prompt_prefix): New proc. (Term::command): Use prompt prefix. (Term::enter_tui): Use command_no_prompt_prefix instead of prefix. * gdb.tui/tui-layout-asm-short-prog.exp: Use command_no_prompt_prefix instead of prefix. * gdb.tui/tui-layout-asm.exp: Same.
2020-03-12gdb: use foreach_with_prefix in gdb.base/break-interp.expSimon Marchi2-137/+137
Use foreach_with_prefix, instead of foreach and with_test_prefix separately. Since allows removing some indentation levels, and formats the test names a bit nicer, in my opinion (or at least, it's more consistent with the rest of the testsuite): - PASS: gdb.base/break-interp.exp: LDprelinkNOdebugNO: BINprelinkNOdebugNOpieNO: INNER: core: set verbose on + PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: set verbose on Note: this patch is better viewed with "git show -w" to ignore whitespace changes. gdb/testsuite/ChangeLog: * gdb.base/break-interp.exp: Use foreach_with_prefix.
2020-03-12gdb: make gdb.arch/amd64-disp-step-avx.exp actually test displaced steppingSimon Marchi3-1/+19
The test gdb.arch/amd64-disp-step-avx.exp is meant to test that doing a displaced step of an AVX instruction works correctly. However, I found (by pure coincidence) that the test instructions are not actually displaced stepped. Rather, they are inline-stepped, so the test is not actually testing what it's meant to test. This is what a portion of the test binary looks like: 0000000000400180 <_start>: 400180: 90 nop 0000000000400181 <main>: 400181: 90 nop 0000000000400182 <test_rip_vex2>: 400182: c5 fb 10 05 0e 00 00 vmovsd 0xe(%rip),%xmm0 # 400198 <ro_var> 400189: 00 000000000040018a <test_rip_vex2_end>: 40018a: 90 nop The instruction at 0x400182 is the one we want to test a displaced step for. A breakpoint is placed at 0x400182 and ran to. The execution is then resumed from there, forcing a step-over (which should normally be a displaced step) of the breakpoint. However, the displaced stepping buffer is at the _start label, and that means a breakpoint is present in the displaced stepping buffer. The breakpoint_in_range_p check in displaced_step_prepare_throw evaluates to true, which makes displaced_step_prepare_throw fail, forcing GDB to fall back on an in-line step. This can be easily observed by placing a `gdb_assert (false)` inside the breakpoint_in_range_p condition, in displaced_step_prepare_throw, and running gdb.arch/amd64-disp-step-avx.exp. The assertion will make the test fail. The proposed fix is to pad `_start` with a bunch of nops so that the test instruction is out of the displaced step buffer. I also think it would be good to enhance the test to make sure that we are testing displaced stepping as intended. I did that by enabling "set debug displaced on" while we step over the interesting instruction, and matching a message printed only when a displaced step is executed. gdb/testsuite/ChangeLog: * gdb.arch/amd64-disp-step-avx.S: Add nops after _start. * gdb.arch/amd64-disp-step-avx.exp: Enable "set debug displaced on" while stepping over the test instruction, match printed message.
2020-03-12[gdb/testsuite] Fix internal buffer full error in gdb.base/info-types.expTom de Vries2-13/+32
With test-case gdb.base/info-types.exp, I run into: ... ERROR: internal buffer is full. UNRESOLVED: gdb.base/info-types.exp: l=c: info types ERROR: internal buffer is full. UNRESOLVED: gdb.base/info-types.exp: l=c++: info types ... Fix this by using exp_continue while matching the output of "info types". Tested on x86_64-linux, using make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-12 Tom de Vries <tdevries@suse.de> * gdb.base/info-types.exp: Use exp_continue during matching of output of "info types".
2020-03-12[gdb/testsuite] Avoid breakpoint in GLIBC in gdb.threads/execl.expTom de Vries2-0/+11
When running the gdb.threads/execl.exp test-case, we run into this FAIL: ... (gdb) continue^M Continuing.^M ^M Thread 1 "execl" hit Breakpoint 2, __GI_execl (path=0x6024a0 \ "build/gdb/testsuite/outputs/gdb.threads/execl/execl1", \ arg=<optimized out>) at execl.c:51^M 51 if (execl (new_image, new_image, NULL) == -1) \ /* set breakpoint here */^M (gdb) FAIL: gdb.threads/execl.exp: continue across exec ... The fail is due to the continue command hitting a breakpoint in __GI_execl rather than main. This problem originates from where we execute the "b 51" command, and get two breakpoint locations: ... (gdb) run ^M Starting program: build/gdb/testsuite/outputs/gdb.threads/execl/execl ^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M ^M Breakpoint 1, main (argc=1, argv=0x7fffffffd3f8) at gdb.threads/execl.c:44^M 44 pthread_create (&thread1, NULL, thread_function, NULL);^M (gdb) b 51^M Breakpoint 2 at 0x400787: gdb.threads/execl.c:51. (2 locations)^M (gdb) PASS: gdb.threads/execl.exp: set breakpoint at execl ... Adding a "info breakpoints" command, we can see the locations: ... (gdb) info breakpoints^M Num Type Disp Enb Address What^M 1 breakpoint keep y 0x00000000004006ee in main at \ gdb.threads/execl.c:44^M breakpoint already hit 1 time^M 2 breakpoint keep y <MULTIPLE> ^M 2.1 y 0x0000000000400787 in main at \ gdb.threads/execl.c:51^M 2.2 y 0x00007ffff758d925 in __GI_execl at \ execl.c:51^M (gdb) PASS: gdb.threads/execl.exp: info breakpoints ... The fact that the __GI_execl breakpoint location is there, is a bug, filed as PR25656. Without debug info for GLIBC though, the bug is not triggered. Fix the FAIL by working around the bug, and deleting the breakpoint after hitting the first breakpoint location. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-12 Tom de Vries <tdevries@suse.de> * gdb.threads/execl.exp: Delete breakpoint after hitting it.
2020-03-12[gdb/testsuite] Fix internal buffer full error in gdb.fortran/module.expTom de Vries2-9/+33
With test-case gdb.fortran/module.exp, I run into: ... PASS: gdb.fortran/module.exp: fully qualified name of DW_TAG_constant ERROR: internal buffer is full. UNRESOLVED: gdb.fortran/module.exp: info variables -n ... Fix this by using exp_continue while matching the output of "info variable -n". Tested on x86_64-linux, using make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-12 Tom de Vries <tdevries@suse.de> * gdb.fortran/module.exp: Use exp_continue during matching of output of "info variable -n".
2020-03-12[gdb/testsuite] Fix dw2-ranges-base.exp FAIL with lib debuginfoTom de Vries2-1/+6
When running test-case gdb.dwarf2/dw2-ranges-base.exp with debuginfo for various libs installed, I run into: ... (gdb) maint info line-table^M ... objfile: /usr/lib/debug/lib64/ld-2.26.so-2.26-lp151.18.7.x86_64.debug \ ((struct objfile *) 0x1a9d7f0)^M compunit_symtab: ((struct compunit_symtab *) 0x2061090)^M symtab: /usr/src/debug/glibc-2.26-lp151.18.7.x86_64/sysdeps/generic/\ dl-fcntl.h ((struct symtab *) 0x2182660)^M linetable: ((struct linetable *) 0x0):^M No line table.^M (gdb) FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table ... The test-case intends to count 3 END markers in the line table for gdb.dwarf2/dw2-ranges-base.c: ... symtab: /data/gdb_versions/devel/binutils-gdb.git/gdb/testsuite/gdb.dwarf2/\ dw2-ranges-base.c ((struct symtab *) 0x2a7e8c0)^M linetable: ((struct linetable *) 0x2a7ea60):^M INDEX LINE ADDRESS IS-STMT^M 0 31 0x00000000004004a7 Y^M 1 21 0x00000000004004ae Y^M 2 END 0x00000000004004ae Y^M 3 11 0x00000000004004ba Y^M 4 END 0x00000000004004ba Y^M 5 END 0x00000000004004c6 Y^M ... but ends up counting 70+ END markers for all line tables. Fix this by limiting the line tables emitted by the maint info line-table command. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-12 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-ranges-base.exp: Limit "maint info line-table" to gdb.dwarf2/dw2-ranges-base.c.
2020-03-12[gdb/testsuite] Fix gdb.linespec/explicit.exp FAIL with glibc debug infoTom de Vries2-1/+24
When running test-case gdb.linespec/explicit.exp with GLIBC debuginfo installed, I run into: ... (gdb) break -source exp^GlFAIL: gdb.linespec/explicit.exp: complete \ non-unique file name (timeout) ... The regexp that times out is: ... -re "break -source exp\\\x07licit" { ... and the reason it times out is that gdb only outputs an "l" after the tab, while the regexp expect a futher "icit". This is a regression since commit 507dd60e28 "[gdb/testsuite, 1/2] Fix gdb.linespec/explicit.exp with check-read1", where I merged the matching for the two cases where GLIBC debuginfo is either installed or not, as it turns out incorrectly, presumably because even though I tested with GLIBC debuginfo info installed and deinstalled, that didn't make a difference because I didn't use configure flag --with-separate-debug-dir=/usr/lib/debug. Fix this by not explictly matching the "icit" part. Tested on x86_64-linux, with and without GLIBC debuginfo installed, both with make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-12 Tom de Vries <tdevries@suse.de> * gdb.linespec/explicit.exp: Fix "complete non-unique file name" test in presence of GLIBC debuginfo.
2020-03-12[gdb/testsuite] Use string_to_regexp on core filename in gdb_core_cmdTom de Vries2-1/+6
In commit 1281424ccf "[gdb/testsuite] Fix core file load FAIL in tls-core.exp", I've made this change: ... - -re ": No such file or directory.*\r\n$gdb_prompt $" { + -re "$core: No such file or directory.*\r\n$gdb_prompt $" { ... However, the $core variable contains a filename which needs to be matched as a literal string, not as a regexp. Fix this by using string_to_regexp. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-12 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_core_cmd): Use string_to_regexp for regexp-matching $core.
2020-03-12[gdb/testsuite] Fix core file load FAIL in tls-core.expTom de Vries2-1/+6
After deinstalling package glibc-debugsource, I run into the following FAIL with test-case gdb.threads/tls-core.exp: ... (gdb) core gdb/testsuite/outputs/gdb.threads/tls-core/tls-core.core^M [New LWP 30081]^M [New LWP 30080]^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M Core was generated by `gdb/testsuite/outputs/gdb.threads/tls-core/tls-c'.^M Program terminated with signal SIGABRT, Aborted.^M 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.^M [Current thread is 1 (Thread 0x7fb568d4b700 (LWP 30081))]^M (gdb) FAIL: gdb.threads/tls-core.exp: native: load core file (file not found) ... The problem is that this gdb_test_multiple clause in gdb_core_cmd: ... -re ": No such file or directory.*\r\n$gdb_prompt $" { fail "$test (file not found)" return -1 } ... triggers on the message about raise.c, while it is intended to catch: ... $ gdb (gdb) core bla /home/vries/bla: No such file or directory. ... Fix this by making the regexp more precise: ... - -re ": No such file or directory.*\r\n$gdb_prompt $" { + -re "$core: No such file or directory.*\r\n$gdb_prompt $" { ... Tested on x86_64-linux. Also tested the test-case with this patch in place to verify that the regexp still triggers: ... - set core_loaded [gdb_core_cmd $corefile $test] + set core_loaded [gdb_core_cmd $corefile/bla $test] ... gdb/testsuite/ChangeLog: 2020-03-12 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_core_cmd): Make "No such file or directory" regexp more precise.
2020-03-11testsuite: use `pwd -W` to convert from Unix to Windows pathsSimon Marchi2-1/+6
When on a MinGW host, standard_output_file uses a regular expression to convert Unix-style paths of the form "/c/foo" to "c:/foo". This is needed because the paths we pass to GDB (for example, with the "file" command) need to be in the Windows form. However, the regexp only works if your binutils-gdb repo is under a `/[a-z]/...` path (the Unix paths mapping to Windows drives). Presumably, that works if you clone the repo in Windows, then access it through `/c/...`. In my case, I've cloned the repository directly inside my MinGW shell, so in /home/smarchi. The regexp therefore doesn't work for me. The path doesn't get transformed, and the file command fails when running any test: (gdb) file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent: No such file or directory. A safer way to do this is to execute `pwd -W` while in the directory we want the path for, this is what this patch does. I have also considered using the using the cygpath utility to do the conversion. It can be used to convert any MinGW path into its Windows equivalent. Despite originally coming from Cygwin, the cygpath utility is distributed by MinGW-w64 and can be used in that environment. However, it's not distributed with the non-MinGW-w64 MinGW. The `pwd -W` trick only works with directories that exist, which is the case here, so it's sufficient. With this, the file command in the test succeeds: (gdb) file C:/msys64/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent Reading symbols from C:/msys64/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent... gdb/testsuite/ChangeLog: * lib/gdb.exp (standard_output_file): Use `pwd -W` to convert from Unix to Windows path.
2020-03-11[gdb/testsuite] Set language in gdb.ada/minsym.expTom de Vries2-0/+6
When building gdb using configure flag --with-separate-debug-dir=/usr/lib/debug, and running test-case gdb.ada/minsyms.exp, I run into: ... (gdb) PASS: gdb.ada/minsyms.exp: print some_minsym print integer(some_minsym)^M A syntax error in expression, near `some_minsym)'.^M (gdb) FAIL: gdb.ada/minsyms.exp: print integer(some_minsym) ... and 2 other FAILs. This is due to the fact that the language after arriving at the ada main function turns out to be auto/c. [ This has been filed as PR25655 - "Language is not auto/ada in main ada function for exec without debug info". ] When building gdb without the configure flag mentioned above, we have instead auto/ada in the ada main function, and all tests pass. Fix the FAILs by working around PR25655 in the test-case, and manually setting the language to ada. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * gdb.ada/minsyms.exp: Set language to ada.
2020-03-11[gdb/testsuite] Fix printf regexp in gdb.server/sysroot.expTom de Vries2-1/+6
When running gdb.server/sysroot.exp, I run into this FAIL: ... (gdb) continue^M Continuing.^M ^M Breakpoint 2, __printf (format=0x4005c4 "Hello World!\n") at printf.c:28^M 28 {^M (gdb) FAIL: gdb.server/sysroot.exp: sysroot=local: continue to printf ... for this test: ... gdb_test "continue" "Breakpoint $decimal.* printf .*" "continue to printf" ... Without debug info for glibc installed, we have instead: ... (gdb) continue^M Continuing.^M ^M Breakpoint 2, 0x00007ffff773c550 in printf () from /lib64/libc.so.6^M (gdb) PASS: gdb.server/sysroot.exp: sysroot=local: continue to printf ... Fix this by allowing for GLIBC's printf alias __printf to be printed: ... gdb_test "continue" "Breakpoint $decimal.* (__)?printf .*" \ "continue to printf" ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * gdb.server/sysroot.exp: Allow GLIBC's printf alias __printf.
2020-03-11[gdb/testsuite] Fix stepi pattern in gdb.btrace/reconnect.expTom de Vries2-1/+5
When running gdb.btrace/reconnect.exp, I run into the follow FAIL: ... (gdb) stepi 19^M 0x00007ffff7dd8b67 59 return (ElfW(Addr)) &_DYNAMIC - \ elf_machine_dynamic ();^M (gdb) FAIL: gdb.btrace/reconnect.exp: first: stepi 19 ... The corresponding test looks like: ... gdb_test "stepi 19" "0x.* in .* from .*" ... which matches the usual: ... (gdb) stepi 19^M 0x00007ffff7dd8b67 in _dl_start () from target:/lib64/ld-linux-x86-64.so.2^M (gdb) PASS: gdb.btrace/reconnect.exp: first: stepi 19 ... which I also get when removing configure flag --with-separate-debug-dir=/usr/lib/debug. Fix this by allowing the source line pattern in the test regexp. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * gdb.btrace/reconnect.exp: Allow source line pattern after stepi.
2020-03-11Mark discriminants as artificial in gdb.dwarf2/variant.expTom Tromey2-0/+7
While working on a variant part patch, I notcied that gdb.dwarf2/variant.exp does not mark the discriminant members as DW_AT_artificial. However, it should, as this is what the real Rust compiler does, and how the Rust language support is supposed to work. gdb/testsuite/ChangeLog 2020-03-11 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/variant.exp: Mark discriminants as artificial.
2020-03-11[gdb/testsuite] Fix FAILs due to verbose in foll-fork.expTom de Vries2-2/+12
When running test-case gdb.base/foll-fork.exp, I see: ... (gdb) catch fork^M Catchpoint 2 (fork)^M Reading in symbols for ../sysdeps/x86/libc-start.c...^M (gdb) FAIL: gdb.base/foll-fork.exp: explicit child follow, set catch fork ... The problem is that the test regexp does not expect the "Reading in symbols" message: ... gdb_test "catch fork" "Catchpoint \[0-9\]* \\(fork\\)" \ "explicit child follow, set catch fork" ... which is generated due to the verbose setting. Fix this by allowing the message in the regexp. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * gdb.base/foll-fork.exp: Allow "Reading in symbols" messages.
2020-03-11[gdb/testsuite] Limit verbose scope in gdb.base/break-interp.expTom de Vries2-0/+12
I'm running into the following failure (and 17 more like it) in gdb.base/break-interp.exp: ... (gdb) bt^M #0 0x00007fde85a3b0c1 in __GI___nanosleep \ (requested_time=requested_time@entry=0x7ffe5044ee70, \ remaining=remaining@entry=0x7ffe5044ee70) at nanosleep.c:27^M #1 0x00007fde85a3affa in __sleep (seconds=0) at sleep.c:55^M #2 0x00007fde8606789c in libfunc (Reading in symbols for libc-start.c...^M action=0x7ffe5044fa12 "sleep") at gdb.base/break-interp-lib.c:41^M #3 0x0000000000400708 in main ()^M Reading in symbols for ../sysdeps/x86_64/start.S...^M (gdb) FAIL: gdb.base/break-interp.exp: LDprelinkNOdebugNO: \ BINprelinkNOdebugNOpieNO: INNER: attach: attach main bt ... The problem is that the test uses verbose mode to detect the "PIE (Position Independent Executable) displacement" messages, but the verbose mode also triggers "Reading in symbols for" messages, which may appear in the middle of a backtrace (or not, depending on whether debug info is available). [ In fact, the messages appear in the middle of a backtrace line, which is PR25613. ] Fix these FAILs by limiting the scope of verbose to the parts of the test that need it. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * gdb.base/break-interp.exp: Limit verbose scope.
2020-03-11[gdb/testsuite] Fix missing uint8_t in gdb.fortran/logical.expTom de Vries3-1/+8
With test-case gdb.fortran/logical.exp, I run into: ... (gdb) PASS: gdb.fortran/logical.exp: var=l: get hexadecimal valueof "&l" set *((uint8_t *) 0x7fffffffd2bc) = 0xff^M No symbol "uint8_t" in current context.^M (gdb) FAIL: gdb.fortran/logical.exp: var=l: byte 0: set contents of byte at offset 0 ... Fix this by using the fortran-native type character instead. Tested on x86_64-linux, with gcc 7.5.0. gdb/testsuite/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * gdb.fortran/logical.f90: Define variable with character type. * gdb.fortran/logical.exp: Use character type instead of uint8_t.
2020-03-11[gdb/testsuite] Set EDITOR to true before using editTom de Vries2-0/+8
The test-case gdb.base/list-ambiguous.exp normally passes, but with target board readnow, some tests fail. In particular, for this test, edit doesn't fail as expected: ... # While at it, test the "edit" command as well, since it shares # code with "list". gdb_test "edit $symbol" \ "Specified line is ambiguous:\r\n${h0_re}\r\n${h1_re}" ... and the editor is launched, in my case: ... $ echo $EDITOR /home/vries/bin/emacs-nw.sh ... which result in all subsequent tests failing with timeout, and an editor backup file in my sources: ... $ git status --ignored On branch master Ignored files: (use "git add -f <file>..." to include in what will be committed) gdb/testsuite/gdb.base/#list-ambiguous0.c# nothing to commit, working tree clean ... Fix this by setting EDITOR to true before starting gdb in this test-case. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * gdb.base/list-ambiguous.exp: Set EDITOR to true.
2020-03-11[gdb] Fix segv in "maint print symbols" for ada execTom de Vries2-0/+15
When using the executable from test-case gdb.ada/access_to_packed_array.exp (read-in using -readnow) and printing the symbols using "maint print symbols", we run into a segv: ... $ gdb -readnow -batch access_to_packed_array/foo -ex "maint print symbols" ... info: array (<>) of character; computed at runtime ptr: range 0 .. 2147483647; computed at runtime Aborted (core dumped) ... What happens is that dwarf2_evaluate_property gets called and sets the local frame variable to the current frame, which happens to be NULL. Subsequently the PROP_LOCLIST handling code is executed, where get_frame_address_in_block gets called with argument NULL, and the segv is triggered. Fix this by handling a NULL frame in the PROP_LOCLIST handling code in dwarf2_evaluate_property. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * dwarf2/loc.c (dwarf2_evaluate_property): Handle NULL frame in PROP_LOCLIST handling code. gdb/testsuite/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * gdb.ada/access_to_packed_array.exp: Test printing of expanded symtabs.
2020-03-10gdb: Add support for tracking the DWARF line table is-stmt fieldAndrew Burgess9-3/+930
This commit brings support for the DWARF line table is_stmt field to GDB. The is_stmt field is used by the compiler when a single source line is split into multiple assembler instructions, especially if the assembler instructions are interleaved with instruction from other source lines. The compiler will set the is_stmt flag false from some instructions from the source lines, these instructions are not a good place to insert a breakpoint in order to stop at the source line. Instructions which are marked with the is_stmt flag true are a good place to insert a breakpoint for that source line. Currently GDB ignores all instructions for which is_stmt is false. This is fine in a lot of cases, however, there are some cases where this means the debug experience is not as good as it could be. Consider stopping at a random instruction, currently this instruction will be attributed to the last line table entry before this point for which is_stmt was true - as these are the only line table entries that GDB tracks. This can easily be incorrect in code with even a low level of optimisation. With is_stmt tracking in place, when stopping at a random instruction we now attribute the instruction back to the real source line, even when is_stmt is false for that instruction in the line table. When inserting breakpoints we still select line table entries for which is_stmt is true, so the breakpoint placing behaviour should not change. When stepping though code (at the line level, not the instruction level) we will still stop at instruction where is_stmt is true, I think this is more likely to be the desired behaviour. Instruction stepping is, of course, unchanged, stepping one instruction at a time, but we should now report more accurate line table information with each instruction step. The original motivation for this work was a patch posted by Bernd here: https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html As part of that thread it was suggested that many issues would be resolved if GDB supported line table views, this isn't something I've attempted in this patch, though reading the spec, it seems like this would be a useful feature to support in GDB in the future. The spec is here: http://dwarfstd.org/ShowIssue.php?issue=170427.1 And Bernd gives a brief description of the benefits here: https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html With that all said, I think that there is benefit to having proper is_stmt support regardless of whether we have views support, so I think we should consider getting this in first, and then building view support on top of this. The gdb.cp/step-and-next-inline.exp test is based off a test proposed by Bernd Edlinger in this message: https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html gdb/ChangeLog: * buildsym-legacy.c (record_line): Pass extra parameter to record_line. * buildsym.c (buildsym_compunit::record_line): Take an extra parameter, reduce duplication in the line table, and record the is_stmt flag in the line table. * buildsym.h (buildsym_compunit::record_line): Add extra parameter. * disasm.c (do_mixed_source_and_assembly_deprecated): Ignore non-statement lines. * dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass this to the symtab builder. (dwarf_finish_line): Pass extra parameter to dwarf_record_line_1. (lnp_state_machine::record_line): Pass a suitable is_stmt flag through to dwarf_record_line_1. * infrun.c (process_event_stop_test): When stepping, don't stop at a non-statement instruction, and only refresh the step info when we land in the middle of a line's range. Also add an extra comment. * jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt field. * record-btrace.c (btrace_find_line_range): Only record lines marked as is-statement. * stack.c (frame_show_address): Show the frame address if we are in a non-statement sal. * symmisc.c (dump_symtab_1): Print the is_stmt flag. (maintenance_print_one_line_table): Print a header for the is_stmt column, and include is_stmt information in the output. * symtab.c (find_pc_sect_line): Find lines marked as statements in preference to non-statements. (find_pcs_for_symtab_line): Prefer is-statement entries. (find_line_common): Likewise. * symtab.h (struct linetable_entry): Add is_stmt field. (struct symtab_and_line): Likewise. * xcoffread.c (arrange_linetable): Initialise is_stmt field when arranging the line table. gdb/testsuite/ChangeLog: * gdb.cp/step-and-next-inline.cc: New file. * gdb.cp/step-and-next-inline.exp: New file. * gdb.cp/step-and-next-inline.h: New file. * gdb.dwarf2/dw2-is-stmt.c: New file. * gdb.dwarf2/dw2-is-stmt.exp: New file. * gdb.dwarf2/dw2-is-stmt-2.c: New file. * gdb.dwarf2/dw2-is-stmt-2.exp: New file. * gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
2020-03-10gdb/testsuite: Add is-stmt support to the DWARF compilerAndrew Burgess2-1/+12
This commit adds the ability to set and toggle the DWARF line table is-stmt flag. A DWARF line table can now be created with the attribute 'default_is_stmt' like this: lines {version 2 default_is_stmt 0} label { ... } If 'default_is_stmt' is not specified then the current default is 1, which matches the existing behaviour. Inside the DWARF line table program you can now make use of {DW_LNS_negate_stmt} to toggle the is-stmt flag, for example this meaningless program: lines {version 2 default_is_stmt 0} label { include_dir "some_directory" file_name "some_filename" 1 program { {DW_LNS_negate_stmt} {DW_LNE_end_sequence} } } This new functionality will be used in a later commit. gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf::lines) Add support for modifying the is-stmt flag in the line table. Change-Id: Ia3f61d523826382dd2333f65b9aae368ad29c4a5
2020-03-09[gdb/testsuite] Fix tcl error in cached_fileTom de Vries2-0/+7
When trying to run tests using target board cc-with-dwz after a clean build, I run into: ... ERROR: tcl error sourcing board description file for target cc-with-tweaks.exp. couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \ no such file or directory couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \ no such file or directory while executing "open $tmp_filename w" (procedure "cached_file" line 9) invoked from within "cached_file gdb.sh "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS \"\$@\"" 1" ... The problem is that cached_file is trying to create a file build/gdb/testsuite/cache/gdb.sh.17028 in a non-existing directory. Fix this by creating the cache dir in cached_file. Tested on x86_64-linux, with target board cc-with-tweaks, and native. gdb/testsuite/ChangeLog: 2020-03-09 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (cached_file): Create cache dir.
2020-03-07[gdb/testsuite] Fix testing build_executable resultTom de Vries3-2/+7
When running with target board unix/-feliminate-dwarf2-dups, we run into these FAILs: ... FAIL: gdb.cp/rvalue-ref-params.exp: print value of f1 on Child&& in f2 FAIL: gdb.cp/ref-params.exp: print value of f1 on Child in main FAIL: gdb.cp/ref-params.exp: print value of f2 on Child in main FAIL: gdb.cp/ref-params.exp: print value of f1 on Child& in f2 FAIL: gdb.cp/ref-params.exp: print mf1(MQ) FAIL: gdb.cp/ref-params.exp: print mf2(MQ) FAIL: gdb.cp/ref-params.exp: print f1(MQR) FAIL: gdb.cp/ref-params.exp: print mf1(MQR) FAIL: gdb.cp/ref-params.exp: print mf2(MQR) ... This is due to comparing the result of build_executable to 1, while build_executable returns either 0 for success, or -1 for failure. Fix this by comparing with -1 instead. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-07 Tom de Vries <tdevries@suse.de> * gdb.cp/ref-params.exp: Compare build_executable result with -1. * gdb.cp/rvalue-ref-params.exp: Same.
2020-03-06[gdb/testsuite] Fix "text file busy" errors with cc-with-tweaks.expTom de Vries3-4/+49
When using target board cc-with-gdb-index.exp and running tests in parallel, we run into: ... gdb compile failed, gdb/contrib/gdb-add-index.sh: line 86: \ build/gdb/testsuite/gdb.sh: Text file busy ... The problem is that because of the parallel test run, gdb.sh is created for every single test-case, and eventually gdb.sh is overwritten while being executed. Fix this by creating gdb.sh only once. Tested on x86_64-linux with target board cc-with-gdb-index.exp, using both a serial and parallel -j 5 test run. gdb/testsuite/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (tentative_rename, cached_file): New proc. * boards/cc-with-tweaks.exp: Use cached_file to create gdb.sh.
2020-03-06[gdb,testsuite,doc,NEWS] Fix "the the".Tom de Vries3-2/+7
Replace "the the" by "the". gdb/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * NEWS: Fix "the the". * ctfread.c: Same. gdb/doc/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * gdb.texinfo: Fix "the the". gdb/testsuite/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * README: Fix "the the". * gdb.base/dprintf.exp: Same.
2020-03-05[gdb/testsuite] Update maint.exp for string cacheTom de Vries2-1/+5
When running gdb.base/maint.exp, I see: ... FAIL: gdb.base/maint.exp: maint print statistics ... This is due to commit be1e3d3eab "Introduce objfile::intern", which replaces the macro and filename caches with a string cache. Update maint.exp accordingly. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-05 Tom de Vries <tdevries@suse.de> * gdb.base/maint.exp: Update "main print statistics" expected output.
2020-03-04gdb.fortran: Allow Flang kind printing in fortran testingAlok Kumar Sharma2-14/+31
In lib/fortran.exp, in the helper function fortran_int4, kind parameter is expected to be printed as (kind=4) for the LLVM Fortran compiler, Flang along with gfortran. And in the helper function fortran_int8 kind parameter is expected to be printed as (kind=8). But for the Flang compiler default kind is not printed and non default kind is printed differently than gfortran as below. integer(kind=4) => integer integer(kind=8) => integer*8 real(kind=4) => real real(kind=8) => double precision complex(kind=4) => complex logical(kind=4) => logical character(kind=1) => character This commit adds support for printing of kind parameter for the Flang. There should be no change when testing with gfortran. Note: The current patch overrides earlier patch with below details. commit c3b149eb7697b376df1b3a47d0102afda389ee6d Author Alok Kumar Sharma (alokkumar.sharma@amd.com) Earlier patch was incomplete and based on assumption that flang should be changed to dump a type with kind like the way gfortan does. Later it was realized that the way flang dumps this info is not incorrect but different. And changes in gdb test framework are finalized. gdb/testsuite/ChangeLog: * lib/fortran.exp (fortran_int4): Handle flang kind printing. (fortran_int8): Likewise. (fortran_real4): Likewise. (fortran_real8): Likewise. (fortran_complex4): Likewise. (fortran_logical4): Likewise. (fortran_character1): Likewise.
2020-03-03gdb/fortran: Fix printing of logical true values for FlangAndrew Burgess2-0/+23
GDB is not able to print logical true values for Flang compiler. Actual result: (gdb) p l $1 = 4294967295 Expected result: (gdb) p l $1 = .TRUE. This is due to GDB expecting representation of true value being 1. The Fortran standard doesnt specify how LOGICAL types are represented. Different compilers use different non-zero values to represent logical true. The gfortran compiler uses 1 to represent logical true and the flang compiler uses -1. GDB should accept all the non-zero values as true. This is achieved by handling TYPE_CODE_BOOL in f_val_print and printing any non-zero value as true. gdb/ChangeLog: * f-valprint.c (f_val_print): Handle TYPE_CODE_BOOL, any non-zero value should be printed as true. gdb/testsuite/ChangeLog: * gdb.fortran/logical.exp: Add tests that any non-zero value is printed as true.
2020-03-03Fix printf of a convenience variable holding an inferior addressSergio Durigan Junior2-0/+13
Back at: commit 1f6f6e21fa86dc3411a6498608f32e9eb24b7851 Author: Philippe Waroquiers <philippe.waroquiers@skynet.be> Date: Mon Jun 10 21:41:51 2019 +0200 Ensure GDB printf command can print convenience var strings without a target. GDB was extended in order to allow the printing of convenience variables that are strings without a target. However, this introduced a regression that hasn't been caught by our testsuite (because there were no tests for it). The problem happens when we try to print a convenience variable that holds the address of a string in the inferior. The following two-liners can reproduce the issue: $ echo -e 'int main(){const char a[]="test";return 0;}' | gcc -x c - -O0-g3 $ ./gdb/gdb --data-directory ./gdb/data-directory -q ./a.out -ex 'start' -ex 'set $x = (const char *) (&a[0] + 2)' -ex 'printf "%s\n", $x' After some investigation, I found that the problem happens on printcmd.c:printf_c_string. In the case above, we're taking the first branch of the 'if' condition, which assumes that there will be a value to be printed at "value_contents (value)". There isn't. We actually need to obtain the address that the variable points to, and read the contents from memory. It seems to me that we should avoid this branch if the TYPE_CODE of "value_type (value)" is TYPE_CODE_PTR (i.e., a pointer to the inferior's memory). This is what this patch does. I took the liberty to extend the current testcase under gdb.base/printcmds.exp and create a test that exercises this scenario. No regressions have been found on Buildbot. gdb/ChangeLog: 2020-03-03 Sergio Durigan Junior <sergiodj@redhat.com> * printcmd.c (print_c_string): Check also for TYPE_CODE_PTR when verifying if dealing with a convenience variable. gdb/testsuite/ChangeLog: 2020-03-03 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.base/printcmds.exp: Add test to verify printf of a variable holding an address.
2020-03-03[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1Tom de Vries2-3/+34
When running gdb.mi/gdb2549.exp with check-read1, we get: ... Running src/gdb/testsuite/gdb.mi/gdb2549.exp ... FAIL: gdb.mi/gdb2549.exp: register values t (timeout) ... The problem is that the command generates a lot of output, which is matched by a single '.*': ... mi_gdb_test "666-data-list-register-values t" \ "666\\^done,register-values=\\\[\{number=\"$decimal\",value=\"$binary\"\}.*\\\]" \ "register values t" ... Fix this by splitting up the matching and calling exp_continue after each number/value pair. Tested on x86_64-linux with make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-03 Tom de Vries <tdevries@suse.de> * gdb.mi/gdb2549.exp: Fix "register values t" check-read1 timeout.
2020-03-03[gdb/testsuite] Fix tcl error in gdb.mi/list-thread-groups-available.expTom de Vries2-2/+9
When running gdb.mi/list-thread-groups-available.exp, we get: ... Running gdb.mi/list-thread-groups-available.exp ... ERROR: tcl error sourcing gdb.mi/list-thread-groups-available.exp. ERROR: Too many arguments to gdb_test_multiple ... The problem is that the gdb_test_multiple call has as last argument a $mi_gdb_prompt, which is no longer supported syntax since 590003dc0e "[gdb/testsuite] Add -lbl option in gdb_test_multiple". Fix this by using the new -prompt syntax. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-03 Tom de Vries <tdevries@suse.de> * gdb.mi/list-thread-groups-available.exp: Use -prompt syntax for gdb_test_multiple call.
generated by cgit v1.1 at 2025-09-20 23:01:29 +0000