aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2019-12-20Fix "list" command in the TUITom Tromey2-0/+38
PR tui/18932 notes that "list" no longer works in the TUI. At some point in the past, it switched the TUI source window to show the specified source; but now this source briefly flashes before the TUI reverts to showing the current stack frame's source. This patch fixes this bug by introducing a new observer that notices when the user selected context has changed. Then, the existing before-prompt observer is updated to request the correct update: either one based on the current stack frame, or one based on the user's source symtab_and_line. gdb/ChangeLog 2019-12-20 Tom Tromey <tom@tromey.com> PR tui/18932: * tui/tui-hooks.c (tui_refresh_frame_and_register_information): Rename parameters. Handle the not-from-stack-frame case. (from_stack, from_source_symtab): New globals. (tui_before_prompt, tui_normal_stop): Update. (tui_context_changed, tui_symtab_changed): New functions. (tui_attach_detach_observers): Attach new observers. gdb/testsuite/ChangeLog 2019-12-20 Tom Tromey <tom@tromey.com> * gdb.tui/list-before.exp: New file. Change-Id: I62013825f6c1afdd568a1c7a8c019b0c881131af
2019-12-20Display "main" on initial TUI startupTom Tromey2-1/+5
I noticed that even when there's a symbol file, "tui enable" won't show "main" by default. I think it should, and this patch fixes this. gdb/ChangeLog 2019-12-20 Tom Tromey <tom@tromey.com> * tui/tui.c (tui_enable): Call tui_display_main. gdb/testsuite/ChangeLog 2019-12-20 Tom Tromey <tom@tromey.com> * gdb.tui/list.exp: Check for source on initial listing. Change-Id: Ic7bfc930e1179f5b61111e30a2dae46a98b00064
2019-12-19Handle CRLF when reading XML on WindowsTom Tromey2-3/+16
xml-support.c uses FOPEN_RT, but then reads the entire contents of the file and verifies that the number of bytes read matches the length. This can fail on Windows, where the read will translate line terminators. This patch fixes the bug by changing xml-support.c to use FOPEN_RB. This works because expat correctly handles \r\n line terminators. gdb/ChangeLog 2019-12-11 Tom Tromey <tromey@adacore.com> * xml-support.c (xml_fetch_content_from_file): Use FOPEN_RB. gdb/testsuite/ChangeLog 2019-12-11 Tom Tromey <tromey@adacore.com> * gdb.xml/tdesc-arch.exp (set_arch): Add "trans_mode" parameter. Add crlf test. Change-Id: I548438f33eed284dde1de8babf755eaa1a40319d
2019-12-18Update gdb.base/default.exp for GDB 10Simon Marchi2-1/+5
Now that the version number in master has been bumped to 10, I get this failure: FAIL: gdb.base/default.exp: show convenience ($_gdb_major = 9 not found) Update the test accordingly. gdb/testsuite/ChangeLog: * gdb.base/default.exp: Update value of $_gdb_major.
2019-12-17Fix skip.exp test failure observed with gcc-9.2.0Bernd Edlinger2-5/+15
We need to step a second time with this gcc version. The first step jumps back to main before entering foo. Previously the control flow was from bar directly to foo. Further ananlysis suggests, that this change in behavior started with gcc-8.1.0 when -gcolumn-info was enabled by default. The option -gcolumn-info was first implemented in gcc-7.1.0 but default-disabled, so you can get the altered behavior already with gcc-7 if you manually enable -gcolumn-info. Previously there was just one point where line 30 (of skip.c) started: [0x00000032] Advance Line by 27 to 28 [0x00000034] Copy [0x00000035] Special opcode 63: advance Address by 4 to 0x4004cb and Line by 2 to 30 [0x00000036] Advance PC by constant 17 to 0x4004dc [0x00000037] Special opcode 7: advance Address by 0 to 0x4004dc and Line by 2 to 32 But with -gcolumn-info enabled, we have line 30 three times with different column: [0x00000034] Advance Line by 27 to 28 [0x00000036] Copy [0x00000037] Set column to 9 [0x00000039] Special opcode 63: advance Address by 4 to 0x4004c6 and Line by 2 to 30 [0x0000003a] Set column to 17 [0x0000003c] Special opcode 75: advance Address by 5 to 0x4004cb and Line by 0 to 30 [0x0000003d] Set column to 3 [0x0000003f] Special opcode 75: advance Address by 5 to 0x4004d0 and Line by 0 to 30 [0x00000040] Special opcode 105: advance Address by 7 to 0x4004d7 and Line by 2 to 32 That could probably be filtered in dwarf2read.c to keep the old behavior, but the new behavior makes still sense, even if we cannot really make use of the column in the line number info for now.
2019-12-17Whitespace fix in gdb.base/skip.expBernd Edlinger2-2/+6
Just use tabs instead of spaces here.
2019-12-16Add a test case for skip with inlined functionsBernd Edlinger3-0/+147
2019-12-16Fix double-free when creating more than one block in JIT debug info readerSimon Marchi5-31/+99
A double-free happens when using a JIT debug info reader that creates more than one block. In the loop that frees blocks in finalize_symtab, at the very end, the gdb_block_iter_tmp variable is set initially, but not changed as the loop advances. If we have two blocks, the first iteration frees the first block, the second iteration frees the second block, but the third iteration tries to free the second block again, as gdb_block_iter_tmp keeps pointing on the second block. Fix it by assigning the gdb_block_iter_tmp variable in the loop. I have improved the jit-reader.exp test to cover this case, by adding a second "JIT-ed" function and creating a block for it. I have renamed the existing function to something I find a bit more descriptive. There are no significant changes to jit-reader.exp itself, only updates following the renaming. The important changes are in jithost.c (generate a new function) and in jitreader.c (create a gdb_block for that function). This was found because of an ASan report: $ ./gdb testsuite/outputs/gdb.base/jit-reader/jit-reader -ex "jit-reader-load /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jitreader.so" -ex r Reading symbols from testsuite/outputs/gdb.base/jit-reader/jit-reader... Starting program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jit-reader ================================================================= ==1751048==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000042eb8 at pc 0x5650ef8eec88 bp 0x7ffe52767290 sp 0x7ffe52767280 READ of size 8 at 0x604000042eb8 thread T0 #0 0x5650ef8eec87 in finalize_symtab /home/simark/src/binutils-gdb/gdb/jit.c:768 #1 0x5650ef8eef88 in jit_object_close_impl /home/simark/src/binutils-gdb/gdb/jit.c:797 #2 0x7fbbda986278 in read_debug_info /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jitreader.c:71 #3 0x5650ef8ef56b in jit_reader_try_read_symtab /home/simark/src/binutils-gdb/gdb/jit.c:850 #4 0x5650ef8effe3 in jit_register_code /home/simark/src/binutils-gdb/gdb/jit.c:948 #5 0x5650ef8f2c92 in jit_event_handler(gdbarch*) /home/simark/src/binutils-gdb/gdb/jit.c:1396 #6 0x5650ef0d137e in handle_jit_event /home/simark/src/binutils-gdb/gdb/breakpoint.c:5470 [snip] 0x604000042eb8 is located 40 bytes inside of 48-byte region [0x604000042e90,0x604000042ec0) freed by thread T0 here: #0 0x7fbbe57376b0 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:122 #1 0x5650ef8f350b in xfree<gdb_block> /home/simark/src/binutils-gdb/gdb/gdbsupport/common-utils.h:62 #2 0x5650ef8eeca9 in finalize_symtab /home/simark/src/binutils-gdb/gdb/jit.c:769 #3 0x5650ef8eef88 in jit_object_close_impl /home/simark/src/binutils-gdb/gdb/jit.c:797 #4 0x7fbbda986278 in read_debug_info /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jitreader.c:71 #5 0x5650ef8ef56b in jit_reader_try_read_symtab /home/simark/src/binutils-gdb/gdb/jit.c:850 #6 0x5650ef8effe3 in jit_register_code /home/simark/src/binutils-gdb/gdb/jit.c:948 #7 0x5650ef8f2c92 in jit_event_handler(gdbarch*) /home/simark/src/binutils-gdb/gdb/jit.c:1396 #8 0x5650ef0d137e in handle_jit_event /home/simark/src/binutils-gdb/gdb/breakpoint.c:5470 [snip] previously allocated by thread T0 here: #0 0x7fbbe5737cd8 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:153 #1 0x5650eef662f3 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100 #2 0x5650ef8f34ea in xcnew<gdb_block> /home/simark/src/binutils-gdb/gdb/gdbsupport/poison.h:122 #3 0x5650ef8ed467 in jit_block_open_impl /home/simark/src/binutils-gdb/gdb/jit.c:557 #4 0x7fbbda98620a in read_debug_info /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jitreader.c:60 #5 0x5650ef8ef56b in jit_reader_try_read_symtab /home/simark/src/binutils-gdb/gdb/jit.c:850 #6 0x5650ef8effe3 in jit_register_code /home/simark/src/binutils-gdb/gdb/jit.c:948 #7 0x5650ef8f2c92 in jit_event_handler(gdbarch*) /home/simark/src/binutils-gdb/gdb/jit.c:1396 #8 0x5650ef0d137e in handle_jit_event /home/simark/src/binutils-gdb/gdb/breakpoint.c:5470 [snip] gdb/ChangeLog: * jit.c (finalize_symtab): Set gdb_block_iter_tmp in loop. gdb/testsuite/ChangeLog: * gdb.base/jit-reader.exp (jit_reader_test): Rename jit_function_00 to jit_function_stack_mangle. * gdb.base/jithost.c (jit_function_t): Rename to... (jit_function_stack_mangle_t): ... this. (jit_function_add_t): New typedef. (jit_function_00_code): Rename to... (jit_function_stack_mangle_code): ... this, make static. (jit_function_add_code): New. (main): Generate "add" function and call it. Adjust to changes in jithost_abi. * gdb.base/jithost.h (struct jithost_abi_bounds): New. (struct jithost_abi) <begin, end>: Remove fields. <object, function_stack_mangle, function_add>: New fields. * gdb.base/jitreader.c (struct reader_state) <code_begin, code_end>: Remove fields. <func_stack_mangle>: New field. (read_debug_info): Adjust to renaming, create block for "add" function. (read_sp, unwind_frame, get_frame_id): Adjust to other changes.
2019-12-11Fix TUI test suite regexpsTom Tromey4-4/+10
Testing on another TUI series showed that some of the regexps in the TUI test suite have been incorrect for a while. In particular, "|" was meant literally in these tests, but was interpreted as pattern alternation due to lack of quoting. This patch fixes the bad tests. I am checking this in. gdb/testsuite/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * gdb.tui/resize.exp: Fix regexp. * gdb.tui/regs.exp: Fix regexps. * gdb.tui/main.exp: Fix regexp. Change-Id: Ib6661361171ac120bb92f4a8aec7efa4bcaa36b9
2019-12-11Re-apply the current layout when resizingTom Tromey3-7/+12
The TUI has separate code for each possible layout to handle the case where the terminal window is resized. With the new layout code, this can all be replaced with a call to tui_apply_current_layout, which simply re-applies the current layout. This results in some small differences in behavior when resizing, so some tests are updated. gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-win.c (tui_resize_all): Remove code, call tui_apply_current_layout. gdb/testsuite/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * gdb.tui/resize.exp: Update. * gdb.tui/empty.exp (layouts): Update. Change-Id: I3dc6c02a753d495d9ab5e8213d550a147198ce6f
2019-12-11First use of tui_layoutTom Tromey5-15/+18
This patch introduces the first use of tui_layout, by changing show_layout to clone and use the appropriate tui_layout. This resulted in one minor layout change, and also in the unintended -- but good -- side effect that the title of each boxed window is now visible. gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-layout.h (tui_apply_current_layout): Declare. * tui/tui-layout.c (standard_layouts, applied_layout): New globals. (tui_apply_current_layout): New function. (show_layout): Set applied_layout. Call tui_apply_current_layout. (show_source_command, show_disasm_command) (show_source_disasm_command, show_data) (show_source_or_disasm_and_command): Remove. (initialize_layouts): New function. (_initialize_tui_layout): Call initialize_layouts. gdb/testsuite/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * gdb.tui/regs.exp: Update. * gdb.tui/empty.exp (layouts): Update. * gdb.tui/basic.exp: Update. * lib/tuiterm.exp (_check_box): Don't check bottom border. Change-Id: If1ee06ee58f4803e8c213f4ab0f5bb59f4650ec2
2019-12-11Implement 'print -raw-values' and 'set print raw-values on|off'Philippe Waroquiers3-0/+27
The option framework documentation was speaking about a 'print -raw' option, but this option does not exist. This patch implements -raw-values option that tells to ignore the active pretty printers when printing a value. As we already have -raw-frame-arguments, I thought -raw-values was more clear, in particular to differentiate set print raw-values and set print raw-frame-arguments. gdb/doc/ChangeLog 2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.texinfo (Command Options): Use -p and -pretty in the example, as -r is ambiguous. Update the print - TAB TAB completion result. (Data): Document new option -raw-values. Use -p and -pretty in the example, as -r is ambiguous. (Print Settings): Document set print raw values. (Pretty-Printer Commands): Document interaction between enabled pretty printers and -raw-values/-raw-frame-arguments. gdb/ChangeLog 2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * NEWS: Document -raw-values option and the related setting commands. * printcmd.c (print_command_parse_format): Do not set opts->raw off, only set it on when /r is given. * valprint.c (value_print_option_defs): New element raw-values. * Makefile.in: Add the new file. gdb/testsuite/ChangeLog 2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.base/options.exp: Add -raw-values in the print completion list. * gdb.python/py-prettyprint.exp: Add tests for -raw-values.
2019-12-10OpenMP parallel region scope testsKevin Buettner3-0/+461
Add tests which check for accessibility of variables from within various OpenMP parallel regions. Tested on Fedora 27, 28, 29, 30, and 31. I also tested with my OpenMP work on Fedora 30. The test has been annotated with setup_xfail and setup_kfail statements so that there are no unexpected failures on any of these platforms when using gcc. Better still, for my own testing anyway, is that there are also no XPASSes or KPASSes either. So, regardless of platform, when using gcc, and regardless of whether my (not yet public) OpenMP work is used, seeing a FAIL indicates a real problem. Fedora 27 results: # of expected passes 85 # of expected failures 65 (Note: I have not retested F27 since v1 of the patch; it's possible that the numbers will be slightly different for v2.) Fedora 28, 29, 30 results: # of expected passes 131 # of expected failures 4 # of known failures 16 Fedora 30, 31 results w/ my OpenMP work: # of expected passes 151 The above results all use gcc, either the system gcc or a development gcc (when testing against my OpenMP work in GDB). I've also tested with clang 9.0.0 and icc 19.0.5.281 20190815 on Fedora 31. Fedora 31, clang: FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s3 FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i1 FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i3 FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s3 FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print i1 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i02 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i11 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print i11 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: multi_scope: after parallel: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print num FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print num FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print num FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print num FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print i FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print j Fedora 31, icc: FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print i FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print j FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print i FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print j FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print k FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print z FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print i FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print j FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print i FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print j FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print k FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print z FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k For both clang and icc, it turns out that there are some problems with the DWARF that these compilers generate. Of the two, icc does at least nest the subprogram of the outlined function representing the parallel region within the function that it's defined, but does not handle inner scopes if they exist. clang places the subprogram for the outlined function at the same level as the containing function, so variables declared within the function aren't visible at all. I could call setup_xfail to avoid FAILs for clang and icc also, but I don't want to further complicate the test. gdb/testsuite/ChangeLog: * gdb.threads/omp-par-scope.c: New file. * gdb/threads/omp-par-scope.exp: New file. Change-Id: Icb9c991730d84ca7509380af817dfcc778e764ea
2019-12-10Add gdb_caching_proc support_nested_function_tests to lib/gdb.expKevin Buettner2-3/+22
This commit adds the gdb_caching_proc, support_nested_function_tests, to lib/gdb.exp. It tests to see whether or not the C compiler has support for nested function calls. gdb/testsuite/ChangeLog: * lib/gdb.exp (support_nested_function_tests): New proc. Change-Id: Ic2c93bc4cc200e07e104a2398f89a9c0514bdc75
2019-12-10Add gdb_compile_openmp to lib/gdb.expKevin Buettner2-2/+19
gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_compile_openmp): New proc. (build_executable_from_specs): Add an "openmp" option. (gdb_compile_pthreads): Add non-executable case. Change-Id: I94048b8b0940c707ce0529a6bcfa6e4eace49101
2019-12-10Normalize Ada ptype to use a single "?"Tom Tromey6-1/+158
Sometimes -- notably with unchecked unions -- the Ada "ptype" code will print a "?" or "??" to indicate something unknown. The choice of what was printed was somewhat arbitrary, and in one case, Ada would print an empty string rather than "?". This patch normalizes the Ada code to use "?" rather than an empty string or "??". My reasoning here is that a single question mark is enough to convey unknown-ness. gdb/ChangeLog 2019-12-10 Tom Tromey <tromey@adacore.com> * ada-typeprint.c (print_choices): Use a single "?". (print_variant_part): Print "?" if the discriminant name is not known. gdb/testsuite/ChangeLog 2019-12-10 Tom Tromey <tromey@adacore.com> * gdb.ada/unchecked_union.exp: New file. * gdb.ada/unchecked_union/pck.adb: New file. * gdb.ada/unchecked_union/pck.ads: New file. * gdb.ada/unchecked_union/unchecked_union.adb: New file. * gdb-utils.exp (string_to_regexp): Also quote "?". Change-Id: I3403040780a155ffa2c44c8e6a04ba86bc810e29
2019-12-09Fix scripted probe breakpointsGeorge Barrett5-0/+66
The documentation for make-breakpoint from the Guile API and the `spec' variant of the gdb.Breakpoint constructor from the Python API state that the format acceptable for location strings is the same as that accepted by the break command. However, using the -probe qualifier at the beginning of the location string causes a GDB internal error as it attempts to decode a probe location in the wrong code path. Without this functionality, there doesn't appear to be another way to set breakpoints on probe points from Python or Guile scripts. This patch introduces a new helper function that returns a breakpoint_ops instance appropriate for a parsed location and updates the Guile and Python bindings to use said function, rather than the current hard-coded use of bkpt_breakpoint_ops. Since this logic is duplicated in the handling of the `break' and `trace' commands, those are also updated to call into the new helper function. gdb/ChangeLog: 2019-12-10 George Barrett <bob@bob131.so> Fix scripted probe breakpoints. * breakpoint.c (tracepoint_probe_breakpoint_ops): Move declaration forward. (breakpoint_ops_for_event_location_type) (breakpoint_ops_for_event_location): Add function definitions. (break_command_1, trace_command): Use breakpoint_ops_for_event_location. * breakpoint.h (breakpoint_ops_for_event_location): Add function declarations. * guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use breakpoint_ops_for_event_location. * python/py-breakpoint.c (bppy_init): Use breakpoint_ops_for_event_location. gdb/testsuite/ChangeLog: 2019-12-10 George Barrett <bob@bob131.so> Test scripted probe breakpoints. * gdb.guile/scm-breakpoint.c (main): Add probe point. * gdb.python/py-breakpoint.c (main): Likewise. * gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe specifier test. * gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise.
2019-12-09gdb: rank an lvalue argument incompatible for an rvalue parameterTankut Baris Aktemur3-0/+23
Passing an lvalue argument to a function that takes an rvalue parameter is not allowed per C++ rules. Consider this function: int g (int &&x) { return x; } Calling g as in int i = 5; int j = g (i); is illegal. For instance, GCC 9.2.1 yields ~~~ test.cpp: In function ‘int main()’: test.cpp:6:14: error: cannot bind rvalue reference of type ‘int&&’ to lvalue of type ‘int’ 6 | int j = g (i); | ^ ~~~ GDB currently allows this function call: ~~~ (gdb) print g(i) $1 = 5 ~~~ Fix this by ranking an lvalue argument incompatible with an rvalue parameter. The behavior after this patch is: ~~~ (gdb) print g(i) Cannot resolve function g to any overloaded instance ~~~ Tested with GCC 9.2.1. gdb/ChangeLog: 2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdbtypes.c (rank_one_type): Return INCOMPATIBLE_TYPE_BADNESS when ranking an lvalue argument for an rvalue parameter. gdb/testsuite/ChangeLog: 2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.cp/rvalue-ref-overload.cc (g): New function that takes an rvalue parameter. * gdb.cp/rvalue-ref-overload.exp: Test calling it with an lvalue parameter. Change-Id: I4a6dfc7dac63efa1e3b9f8f391e4b736fbdccdc1
2019-12-09gdb/fortran: Improve output pattern in gdb.mi/mi-fortran-modules.expAndrew Burgess2-4/+16
Extend the output pattern in mi-fortran-modules.exp to skip some system modules that appear with versions of GFortran after 7.x.x. gdb/testsuite/ChangeLog: * gdb.mi/mi-fortran-modules.exp: Add patterns to skip system modules. Change-Id: I64aaa395e554a32e8267ffa096faee53c19c0b9e
2019-12-09gdb/testsuite: kfail some tests if using broken gccAndrew Burgess2-0/+11
In some cases the Fortran stride information generated by GCC is wrong with versions of GCC after 7.x.x. This commit adds kfails for the tests in question with known bad versions of gcc. The bug has been reported to GCC here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775 gdb/testsuite/ChangeLog: * gdb.fortran/derived-type-striding.exp: KFAIL if we are using a broken version of GCC. Change-Id: Iaef08e5e2c87ab3d6983b88f749d40e01aea2bc6
2019-12-09gdb/testsuite/fortran: Fix info-modules/info-types for gfortran 8+Andrew Burgess4-140/+648
The gdb.fortran/info-modules.exp and gdb.fortran/info-types.exp tests are failing on versions of gfortran after 7.3 due to the inclusion of extra "system" modules and type that were not being matched by the current test patterns. Rather than building increasingly complex patterns that would always be at risk of breaking with future versions of GCC I have instead added a new library that parses the output of the following commands: info types info variables info functions info modules info module functions info module variables into a data structure, the test can than run checks against the contents of this data structure. The benefit is that we can simply ignore extra results that we don't care about. There is a small risk that a bug in GDB might allow us to start reporting incorrect results in such a way that the new library will not spot the error. However, I have tried to mitigate this risk by adding extra procedures into the test library (see check_no_entry) and we can add more in future if we wanted to be even more defensive. I tested this test file with gFortran 7.3.1, 8.3.0, and 9.2.0, I now see 100% pass in all cases. gdb/testsuite/ChangeLog: * gdb.fortran/info-modules.exp: Rewrite to make use of new sym-info-cmds library. * gdb.fortran/info-types.exp: Likewise. * lib/sym-info-cmds.exp: New file. Change-Id: Iff81624f51b5afb6c95393932f3d94472d7c2970
2019-12-08Fix inter-CU references using intra-CU form in imported-unitTom de Vries2-5/+9
When running the gdb testsuite with the cc-with-dwz board, I run into: ... Running gdb/testsuite/gdb.dwarf2/imported-unit.exp ... gdb compile failed, dwz: gdb.dwarf2/imported-unit/imported-unit: \ Couldn't find DIE referenced by DW_AT_abstract_origin cc-with-tweaks.sh: dwz did not modify gdb.dwarf2/imported-unit/imported-unit. ... The problem is that the DW_AT_abstract_origin reference here: ... <0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit) <1><e6>: Abbrev Number: 4 (DW_TAG_subprogram) <e7> DW_AT_abstract_origin: <0x142> <eb> DW_AT_low_pc : 0x4004b2 <f3> DW_AT_high_pc : 0x4004c8 ... referring to a DIE in another compilation unit here: ... <0><129>: Abbrev Number: 2 (DW_TAG_compile_unit) <1><142>: Abbrev Number: 4 (DW_TAG_subprogram) <143> DW_AT_name : main <148> DW_AT_type : <0x13b> <14c> DW_AT_external : 1 ... is encoded using intra-CU reference form DW_FORM_ref4 instead of intra-CU reference DW_FORM_ref_addr: ... 4 DW_TAG_subprogram [has children] DW_AT_abstract_origin DW_FORM_ref4 DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_addr DW_AT value: 0 DW_FORM value: 0 ... Fix this in the DWARF assembler by making all inter-CU references use the '%' label prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-12-08 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/imported-unit.exp: Fix inter-CU references. Change-Id: I690ff18c3943705ed478453531b176ff74700f3c
2019-12-07Core file build-id supportKeith Seitz5-0/+408
This patch uses new BFD support for detecting build-ids in core files. After this patch, it is possible to run gdb with only the core file, and gdb will automatically load the executable and debug info [example from tests]: $ gdb -nx -q (gdb) core-file corefile-buildid.core [New LWP 29471] Reading symbols from gdb.base/corefile-buildid/debugdir-exec/.build-id/36/fe5722c5a7ca3ac746a84e223c6a2a69193a24... Core was generated by `outputs/gdb.base/coref'. Program terminated with signal SIGABRT, Aborted. (gdb) This work is based on functionality available in Fedora originally written by Jan Kratochvil. Regression tested on buildbot. gdb/ChangeLog: 2019-12-07 Keith Seitz <keiths@redhat.com> * build-id.c (build_id_bfd_get): Permit bfd_core, too. (build_id_to_debug_bfd): Make static, rewriting to use build_id_to_bfd_suffix. (build_id_to_bfd_suffix): Copy of build_id_to_debug_bfd, adding `suffix' parameter. Append SUFFIX to file names when searching for matching files. (build_id_to_debug_bfd): Use build_id_to_bfd_suffix. (build_id_to_exec_bfd): Likewise. * build-id.h (build_id_to_debug_bfd): Clarify that function searches for BFD of debug info file. (build_id_to_exec_bfd): Declare. * corelow.c: Include build-id.h. (locate_exec_from_corefile_build_id): New function. (core_target_open): If no executable BFD is found, search for a core file BFD using build-id. gdb/testsuite/ChangeLog: 2019-12-07 Keith Seitz <keiths@redhat.com> * gdb.base/corefile-buildid-shlib-shr.c: New file. * gdb.base/corefile-buildid-shlib.c: New file. * gdb.base/corefile-buildid.c: New file. * gdb.base/corefile-buildid.exp: New file. Change-Id: I15e9e8e58f10c68b5cae55e2eba58df1e8aef529
2019-12-06[gdb/symtab] Prefer var def over declTom de Vries2-6/+46
Consider the DWARF as generated by gcc with the tentative patch to fix gcc PR91507 - "wrong debug for completed array with previous incomplete declaration": ... <1><f4>: Abbrev Number: 2 (DW_TAG_array_type) <f5> DW_AT_type : <0xff> <f9> DW_AT_sibling : <0xff> <2><fd>: Abbrev Number: 3 (DW_TAG_subrange_type) <2><fe>: Abbrev Number: 0 <1><ff>: Abbrev Number: 4 (DW_TAG_pointer_type) <100> DW_AT_byte_size : 8 <101> DW_AT_type : <0x105> <1><105>: Abbrev Number: 5 (DW_TAG_base_type) <106> DW_AT_byte_size : 1 <107> DW_AT_encoding : 6 (signed char) <108> DW_AT_name : (indirect string, offset: 0x19f): char <1><10c>: Abbrev Number: 6 (DW_TAG_variable) <10d> DW_AT_name : zzz <111> DW_AT_decl_file : 1 <112> DW_AT_decl_line : 1 <113> DW_AT_decl_column : 14 <114> DW_AT_type : <0xf4> <118> DW_AT_external : 1 <118> DW_AT_declaration : 1 <1><118>: Abbrev Number: 2 (DW_TAG_array_type) <119> DW_AT_type : <0xff> <11d> DW_AT_sibling : <0x128> <1><12f>: Abbrev Number: 8 (DW_TAG_variable) <130> DW_AT_specification: <0x10c> <134> DW_AT_decl_line : 2 <135> DW_AT_decl_column : 7 <136> DW_AT_type : <0x118> <13a> DW_AT_location : 9 byte block: 3 30 10 60 0 0 0 0 0 (DW_OP_addr: 601030) ... The DWARF will result in two entries in the symbol table, a decl with type char *[] and a def with type char*[2]. When trying to print the value of zzz: ... $ gdb a.spec.out -batch -ex "p zzz" ... the decl (rather than the def) will be found in the symbol table, which is missing the location information, and consequently we get: ... $1 = 0x601030 <zzz> ... [ There is a fallback mechanism that finds the address of the variable in the minimal symbol table, but that's not used here, because the type of the decl does not specify a size. We could use the symbol size here to get the size of the type, but that's currently not done: PR exp/24989. Still, fixing that PR would not fix the generic case, where minimal symbol info is not available. ] Fix this by preferring defs over decls when searching in the symbol table. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2019-12-06 Tom de Vries <tdevries@suse.de> PR symtab/24971 * block.c (best_symbol, better_symbol): New function. (block_lookup_symbol_primary, block_lookup_symbol): Prefer def over decl. gdb/testsuite/ChangeLog: 2019-12-06 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/varval.exp: Add decl before def test. Change-Id: Id92326cb8ef9903b121ef9e320658eb565d0f5a9
2019-12-06gdb/testsuite: do minor clean-up in gdb.cp/rvalue-ref-overload.expTankut Baris Aktemur2-9/+9
Simplify the expected test outputs. This is a minor cleanup; no functional change is intended. gdb/testsuite/ChangeLog: 2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.cp/rvalue-ref-overload.exp: Minor cleanup. Change-Id: Ie760a2856cae3be0eeed5496765a5f1cd102d6b7
2019-12-06gdb: fix overload resolution for see-through referencesTankut Baris Aktemur3-0/+19
The overload resolution mechanism assigns badness values to the necessary conversions to be made on types to pick a champion. A badness value consists of a "rank" that scores the conversion and a "subrank" to differentiate conversions of the same kind. An auxiliary function, 'sum_ranks', is used for adding two badness values. In all of its uses, except two, 'sum_ranks' is used for populating the subrank of a badness value. The two exceptions are in 'rank_one_type': ~~~ /* See through references, since we can almost make non-references references. */ if (TYPE_IS_REFERENCE (arg)) return (sum_ranks (rank_one_type (parm, TYPE_TARGET_TYPE (arg), NULL), REFERENCE_CONVERSION_BADNESS)); if (TYPE_IS_REFERENCE (parm)) return (sum_ranks (rank_one_type (TYPE_TARGET_TYPE (parm), arg, NULL), REFERENCE_CONVERSION_BADNESS)); ~~~ Here, the result of a recursive call is combined with REFERENCE_CONVERSION_BADNESS. This leads to the problem of over-punishment by combining two ranks. Consider this: void an_overloaded_function (const foo &); void an_overloaded_function (const foo &&); ... foo arg; an_overloaded_function(arg); When ranking 'an_overloaded_function (const foo &)', the badness values REFERENCE_CONVERSION_BADNESS and CV_CONVERSION_BADNESS are combined, whereas 'rank_one_type' assigns only the REFERENCE_CONVERSION_BADNESS value to 'an_overloaded_function (const foo &&)' (there is a different execution flow for that). This yields in GDB picking the latter function as the overload champion instead of the former. In fact, the 'rank_one_type' function should have given 'an_overloaded_function (const foo &)' the CV_CONVERSION_BADNESS value, with the see-through referencing increasing the subrank a little bit. This can be achieved by introducing a new badness value, REFERENCE_SEE_THROUGH_BADNESS, which bumps up the subrank only, and using it in the two "exceptional" cases of 'sum_ranks'. gdb/ChangeLog: 2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdbtypes.h: Define the REFERENCE_SEE_THROUGH_BADNESS value. * gdbtypes.c (rank_one_type): Use REFERENCE_SEE_THROUGH_BADNESS for ranking see-through reference cases. gdb/testsuite/ChangeLog: 2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.cp/rvalue-ref-overload.cc: Add a case that involves both CV and reference conversion for overload resolution. * gdb.cp/rvalue-ref-overload.exp: Test it. Change-Id: I39ae6505ab85ad0bd21915368c82540ceeb3aae9
2019-12-06Fix crash when command arg is missing in faas/taas/tfaas commands.Philippe Waroquiers3-1/+12
GDB crashes when doing: (gdb) faas Aborted Do the needed check to avoid crashing. gdb/ChangeLog 2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be> * stack.c (faas_command): Check a command is provided. * thread.c (taas_command, tfaas_command): Likewise. gdb/testsuite/ChangeLog 2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.threads/pthreads.exp: Test taas and tfaas without command. * gdb.base/frameapply.exp: Test faas without command.
2019-12-04gdb/testsuite: Use -J option when compiling Fortran testsAndrew Burgess3-1/+18
When compiling Fortran tests (e.g. gdb.fortran/info-modules.exp), the Fotran compile produces .mod files. These files contain details of compiled modules that are then consumed by the compiler when compiling other files that USE a module. Currently the compiler writes the .mod files into its current directory, so for us this turns out to be 'build/gdb/testsuite/'. This means that .mod files can be shared between tests, which seems against the spirit of the GDB testsuite; source files should be compiled fresh for each test. This commit adds the -J option to the compiler flags whenever we compile a Fortran file, this option tells the compiler where to write, and look for, .mod files. After this commit there was one Fortran test that needed fixing, with that fix in place all of the Fortran tests pass again, but now the .mod files are now produced in the per-test output directories. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_compile): Add -J compiler option when building Fortran tests. * gdb.mi/mi-fortran-modules.exp: Compile source files in correct order. Change-Id: I99444cf22d80e320093d3f3ed9abb8825f378e0b
2019-12-04gdb/fortran: Support for single/double type modifiersAndrew Burgess2-2/+26
Extend the Fortran parser to support 'single precision' and 'double precision' types as well 'single complex' and 'double complex' types. gdb/ChangeLog: * f-exp.y (COMPLEX_KEYWORD, SINGLE, DOUBLE, PRECISION): New tokens. (typebase): New patterns for complex, single/double precision, and single/double complex. (f77_keywords): Change token for complex keyword, and add single, double, and precision keywords. gdb/testsuite/ChangeLog: * gdb.fortran/type-kinds.exp (test_cast_1_to_type_kind): Handle casting to type with no kind specified. (test_basic_parsing_of_type_kinds): Additional tests for types with no kind specified, and add tests for single/double precision/complex types. Change-Id: I9c82f4d392c58607747bd08862c1ee330723a1ba
2019-12-04Add bit-field test for scalar_storage_orderTom Tromey3-3/+11
This adds a bit-field test for scalar_storage_order. gdb/testsuite/ChangeLog 2019-12-04 Tom Tromey <tromey@adacore.com> * gdb.base/endianity.c (struct other) <x>: New field. (main): Initialize it. * gdb.base/endianity.exp: Update. Change-Id: I9e07d1b3e08e7c3384832b68ef286afe1d11479a
2019-12-04Propagate endianity to subrange typesTom Tromey5-0/+130
A subrange type should inherit its endianity from its base type. gdb/ChangeLog 2019-12-04 Tom Tromey <tromey@adacore.com> * gdbtypes.c (create_range_type): Inherit endianity from base type. gdb/testsuite/ChangeLog 2019-12-04 Tom Tromey <tromey@adacore.com> * gdb.ada/scalar_storage/storage.adb: New file. * gdb.ada/scalar_storage/pck.adb: New file. * gdb.ada/scalar_storage/pck.ads: New file. * gdb.ada/scalar_storage.exp: New file. Change-Id: I2998ab919dc28aeff097763c4242f9bfb90823a3
2019-12-04Add scalar_storage_order support for floating pointTom Tromey3-3/+16
Testing the scalar_storage_order patch pointed out that it does not handle floating point properly. This patch fixes this problem. gdb/ChangeLog 2019-12-04 Tom Tromey <tromey@adacore.com> * dwarf2read.c (dwarf2_init_float_type) (dwarf2_init_complex_target_type): Add byte_order parameter. (read_base_type): Compute byte order earlier. * gdbtypes.c (init_float_type): Add byte_order parameter. * gdbtypes.h (init_float_type): Add byte_order parameter. gdb/testsuite/ChangeLog 2019-12-04 Tom Tromey <tromey@adacore.com> * gdb.base/endianity.c (struct otherendian) <f>: New field. (main): Initialize it. * gdb.base/endianity.exp: Update. Change-Id: Ic02eb711d80ce678ef0ecf8c506a626e441b8440
2019-12-04gdb/mi: Add -max-results parameter to some -symbol-info-* commandsAndrew Burgess2-0/+25
Adds a new parameter -max-results to -symbol-info-functions, -symbol-info-variables, -symbol-info-types, and -symbol-info-modules. This parameter limits the number of results returned. This change still leaves -symbol-info-module-functions and -symbol-info-module-variables always returning all results, fixing these commands is slightly harder. There's currently no mechanism for the user of these commands to know if the result list has been truncated if you get back the maximum number of results, so if there are exactly 10 functions and you call '-symbol-info-functions --max-results 10' the reply would appear no different than if you had 20 functions and called with a max of 10. Right now, if you get back the maximum then you should assume that there might be more results available. One other thing to note is that the global_symbol_searcher::search by default returns SIZE_MAX results, there's no longer a mechanism to return an unlimited number of results, though hopefully this will not be a huge issue. gdb/ChangeLog: * mi/mi-symbol-cmds.c (mi_symbol_info): Take extra parameter, and add it into the search spec. (parse_max_results_option): New function. (mi_info_functions_or_variables): Parse -max-results flag and pass it to mi_symbol_info. (mi_cmd_symbol_info_modules): Likewise. (mi_cmd_symbol_info_types): Likewise. * symtab.c (global_symbol_searcher::add_matching_symbols): Change return type to bool, change result container into a set, and don't add new results if we have enough already. (global_symbol_searcher::add_matching_msymbols): Change return type to bool, and don't add new results if we have enough already. (sort_search_symbols_remove_dups): Delete. (global_symbol_searcher::search): Early exit from search loop when we have enough results. Use a std::set to collect the results from calling add_matching_symbols. * symtab.h (global_symbol_searcher) <set_max_seach_results>: New member function. (global_symbol_searcher) <m_max_search_results>: New member variable. (global_symbol_searcher) <add_matching_symbols>: Update header comment and change return type to bool. (global_symbol_searcher) <add_matching_msymbols>: Update header comment and change return type to bool. gdb/doc/ChangeLog: * doc/gdb.texinfo (GDB/MI Symbol Query): Add documentation of -max-results to some -symbol-info-* commands. gdb/testsuite/ChangeLog: * gdb.mi/mi-sym-info.exp: Add tests for -max-results parameter. Change-Id: I90a28feb55b388fb46461a096c5db08b6b0bd427
2019-12-04gdb/mi: Add -symbol-info-module-{variables,functions}Andrew Burgess2-1/+29
Two new MI command -symbol-info-module-variables and -symbol-info-module-functions, which are the equivalent of the CLI command 'info module variables' and 'info module functions'. These return information about functions and variables within Fortran modules. gdb/ChangeLog: * mi/mi-cmds.c (mi_cmds): Add -symbol-info-module-functions and -symbol-info-module-variables entries. * mi/mi-cmds.h (mi_cmd_symbol_info_module_functions): Declare. (mi_cmd_symbol_info_module_variables): Declare. * mi/mi-symbol-cmds.c (module_symbol_search_iterator): New typedef. (output_module_symbols_in_single_module_and_file): New function. (output_module_symbols_in_single_module): New function. (mi_info_module_functions_or_variables): New function. (mi_cmd_symbol_info_module_functions): New function. (mi_cmd_symbol_info_module_variables): New function. * NEWS: Mention new MI command. gdb/doc/ChangeLog: * doc/gdb.texinfo (GDB/MI Symbol Query): Document new MI command -symbol-info-module-functions and -symbol-info-module-variables. gdb/testsuite/ChangeLog: * gdb.mi/mi-fortran-modules.exp: Add additional tests for -symbol-info-module-functions and -symbol-info-module-variables. Change-Id: Ic96f12dd14bd7e34774c3cde008fec30a4055bfe
2019-12-01gdb: Dynamic string length supportAndrew Burgess2-1/+14
Add support for strings with dynamic length using the DWARF attribute DW_AT_string_length. Currently gFortran generates DWARF for some strings that make use of DW_AT_string_length like this: <1><2cc>: Abbrev Number: 20 (DW_TAG_string_type) <2cd> DW_AT_string_length: 5 byte block: 99 bd 1 0 0 (DW_OP_call4: <0x1bd>) <2d3> DW_AT_byte_size : 4 <2d4> DW_AT_sibling : <0x2e2> In this type entry the DW_AT_string_length attribute references a second DW_TAG_formal_parameter that contains the string length. The DW_AT_byte_size indicates that the length is a 4-byte value. This commit extends GDB's DWARF parsing for strings so that we can create dynamic types as well as static types, based on the attribute the DWARF contains. I then extend the dynamic type resolution code in gdbtypes.c to add support for resolving dynamic strings. gdb/ChangeLog: * dwarf2read.c (read_tag_string_type): Read the fields required to make a dynamic string, and possibly create a dynamic range for the string. (attr_to_dynamic_prop): Setup is_reference based on the type of attribute being processed. * gdbtypes.c (is_dynamic_type_internal): Handle TYPE_CODE_STRING. (resolve_dynamic_array): Rename to... (resolve_dynamic_array_or_string): ...this, update header comment, and accept TYPE_CODE_STRING. (resolve_dynamic_type_internal): Handle TYPE_CODE_STRING. gdb/testsuite/ChangeLog: * gdb.fortran/array-slices.exp: Add test for dynamic strings. Change-Id: I03f2d181b26156f48f27a03c8a59f9bd4d71ac17
2019-12-01gdb/fortran: array stride supportAndrew Burgess5-0/+216
Currently GDB supports a byte or bit stride on arrays, in DWARF this would be DW_AT_bit_stride or DW_AT_byte_stride on DW_TAG_array_type. However, DWARF can also support DW_AT_byte_stride or DW_AT_bit_stride on DW_TAG_subrange_type, the tag used to describe each dimension of an array. Strides on subranges are used by gFortran to represent Fortran arrays, and this commit adds support for this to GDB. I've extended the range_bounds struct to include the stride information. The name is possibly a little inaccurate now, but this still sort of makes sense, the structure represents information about the bounds of the range, and also how to move from the lower to the upper bound (the stride). I've added initial support for bit strides, but I've never actually seen an example of this being generated. Further, I don't really see right now how GDB would currently handle a bit stride that was not a multiple of the byte size as the code in, for example, valarith.c:value_subscripted_rvalue seems geared around byte addressing. As a consequence if we see a bit stride that is not a multiple of 8 then GDB will give an error. gdb/ChangeLog: * dwarf2read.c (read_subrange_type): Read bit and byte stride and create a range with stride where appropriate. * f-valprint.c: Include 'gdbarch.h'. (f77_print_array_1): Take the stride into account when walking the array. Also convert the stride into addressable units. * gdbtypes.c (create_range_type): Initialise the stride to constant zero. (create_range_type_with_stride): New function, initialise the range as normal, and then setup the stride. (has_static_range): Include the stride here. Also change the return type to bool. (create_array_type_with_stride): Consider the range stride if the array isn't given its own stride. (resolve_dynamic_range): Resolve the stride if needed. * gdbtypes.h (struct range_bounds) <stride>: New member variable. (struct range_bounds) <flag_is_byte_stride>: New member variable. (TYPE_BIT_STRIDE): Define. (TYPE_ARRAY_BIT_STRIDE): Define. (create_range_type_with_stride): Declare. * valarith.c (value_subscripted_rvalue): Take range stride into account when walking the array. gdb/testsuite/ChangeLog: * gdb.fortran/derived-type-striding.exp: New file. * gdb.fortran/derived-type-striding.f90: New file. * gdb.fortran/array-slices.exp: New file. * gdb.fortran/array-slices.f90: New file. Change-Id: I9af2bcd1f2d4c56f76f5f3f9f89d8f06bef10d9a
2019-11-30Allow . character as part of command names.Philippe Waroquiers3-1/+32
This patch adds . as an allowed character for user defined commands. Combined with 'define-prefix', this allows to e.g. define a set of Valgrind specific user command corresponding to the Valgrind monitor commands (such as check_memory, v.info, v.set, ...). gdb/ChangeLog 2019-11-30 Philippe Waroquiers <philippe.waroquiers@skynet.be> * command.h (valid_cmd_char_p): Declare. * cli/cli-decode.c (valid_cmd_char_p): New function factorizing the check of valid command char. (find_command_name_length, valid_user_defined_cmd_name_p): Use valid_cmd_char_p. * cli/cli-script.c (validate_comname): Likewise. * completer.c (gdb_completer_command_word_break_characters): Do not remove . from the word break char, update comments. (complete_line_internal_1): Use valid_cmd_char_p. * guile/scm-cmd.c (gdbscm_parse_command_name): Likewise. * python/py-cmd.c (gdbpy_parse_command_name): Likewise. gdb/testsuite/ChangeLog 2019-11-30 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.base/define.exp: Test . in command names. * gdb.base/setshow.exp: Update test, as . is now part of command name.
2019-11-30Test define-prefix.Philippe Waroquiers2-0/+168
Adds a test testing the new define-prefix command. 2019-11-30 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.base/define-prefix.exp: New file.
2019-11-28gdb/testsuite: Fix minor bug in skip_btrace*tests procsAndrew Burgess2-2/+8
The two guard functions skip_btrace_tests and skip_btrace_pt_tests have a minor bug, if the check function fails to compile then surely we should skip the btrace tests - currently we return 0 to indicate don't skip. gdb/testsuite/ChangeLog: * lib/gdb.exp (skip_btrace_tests): Return 1 if the test fails to compile. (skip_btrace_pt_tests): Likewise. Change-Id: I6dfc04b4adcf5b9424fb542ece7ddbe751bee301
2019-11-27gdb/testsuite: Fix race condition compiling fortran testAndrew Burgess2-1/+6
The Fortran test gdb.fortran/info-modules compiles the files info-types.f90 and info-types-2.f90 in that order. Unfortunately info-types.f90 makes use of a module defined in info-types-2.f90. This currently doesn't cause a problem if you run all of the Fortran tests as the info-types.exp test already compiles info-types-2.f90 and so the module description file 'mod2.mod' will be created, and can then be found by info-modules.exp during its compile. If however you try to run just info-modules.exp in a clean build directory, the test will fail to compile. Fix this by compiling the source files in the reverse order so that the module is compiled first, then the test program that uses the module. gdb/testsuite/ChangeLog: * gdb.fortran/info-modules.exp: Compile source files in correct order. Change-Id: Ic3a1eded0486f6264ebe3066cf1beafbd2534a91
2019-11-27Test case for BZ 25065Kevin Buettner3-0/+218
Running a GDB with the fix for BZ 25065 should cause these new tests to all pass. When run against a GDB without the fix, there will be 2 unresolved testcases. This is what I see in the gdb.sum file when I try it using a GDB without the fix: ERROR: GDB process no longer exists UNRESOLVED: gdb.dwarf2/imported-unit.exp: ptype main::Foo ERROR: Couldn't send ptype main::foo to GDB. UNRESOLVED: gdb.dwarf2/imported-unit.exp: ptype main::foo These are "unresolved" versus outright failures due to the fact that GDB dies (segfaults) during the running of the test. gdb/testsuite/ChangeLog: * gdb.dwarf2/imported-unit.exp: New file. * gdb.dwarf2/imported-unit.c: New file. Change-Id: I073fe69b81bd258951615f752df8e95b6e33a271
2019-11-27gdb/mi: Add -symbol-info-modules commandAndrew Burgess4-0/+178
Add '-symbol-info-modules', an MI version of the CLI 'info modules' command. gdb/ChangeLog: * mi/mi-cmds.c (mi_cmds): Add 'symbol-info-modules' entry. * mi/mi-cmds.h (mi_cmd_symbol_info_modules): Declare. * mi/mi-symbol-cmds.c (mi_cmd_symbol_info_modules): New function. * NEWS: Mention new MI command. gdb/testsuite/ChangeLog: * gdb.mi/mi-fortran-modules-2.f90: New file. * gdb.mi/mi-fortran-modules.exp: New file. * gdb.mi/mi-fortran-modules.f90: New file. gdb/doc/ChangeLog: * doc/gdb.texinfo (GDB/MI Symbol Query): Document new MI command -symbol-info-modules. Change-Id: Ibc618010d1d5f36ae8a8baba4fb9d9d724e62b0f
2019-11-27gdb/mi: Add new commands -symbol-info-{functions,variables,types}Andrew Burgess4-0/+226
Add new MI commands -symbol-info-functions, -symbol-info-variables, and -symbol-info-types which correspond to the CLI commands 'info functions', 'info variables', and 'info types' respectively. gdb/ChangeLog: * mi/mi-cmds.c (mi_cmds): Add '-symbol-info-functions', '-symbol-info-types', and '-symbol-info-variables'. * mi/mi-cmds.h (mi_cmd_symbol_info_functions): Declare. (mi_cmd_symbol_info_types): Declare. (mi_cmd_symbol_info_variables): Declare. * mi/mi-symbol-cmds.c: Add 'source.h' and 'mi-getopt.h' includes. (output_debug_symbol): New function. (output_nondebug_symbol): New function. (mi_symbol_info): New function. (mi_info_functions_or_variables): New function. (mi_cmd_symbol_info_functions): New function. (mi_cmd_symbol_info_types): New function. (mi_cmd_symbol_info_variables): New function. * NEWS: Mention new commands. gdb/testsuite/ChangeLog: * gdb.mi/mi-sym-info-1.c: New file. * gdb.mi/mi-sym-info-2.c: New file. * gdb.mi/mi-sym-info.exp: New file. gdb/doc/ChangeLog: * doc/gdb.texinfo (GDB/MI Symbol Query): Document new MI command -symbol-info-functions, -symbol-info-types, and -symbol-info-variables. Change-Id: Ic2fc6a6750bbce91cdde2344791014e5ef45642d
2019-11-26Fix gdbserver ChangeLog entryTom Tromey1-0/+5
Christian pointed out that I had accidentally put a ChangeLog entry into gdbserver that was meant for testsuite. I'm checking in this patch to fix it. Change-Id: Iba6124cea6f63539ad66494d3355fb657b78a66d
2019-11-22Avoid crash in print_ada_task_infoTom Tromey2-1/+10
In MI mode, print_ada_task_info can crash in find_thread_ptid when trying to print an Ada task that is no longer alive. This patch avoids the problem by checking for this case. Because this is Ada-specific, and because Joel approved it internally, I am checking it in. gdb/ChangeLog 2019-11-22 Tom Tromey <tromey@adacore.com> * ada-tasks.c (ada_task_is_alive): Make parameter const. (print_ada_task_info): Don't try to fetch thread id if task is not alive. gdb/gdbserver/ChangeLog 2019-11-22 Tom Tromey <tromey@adacore.com> * gdb.ada/tasks.exp: Add -ada-task-info regression test. * gdb.ada/tasks/foo.adb: Add another stopping location. Change-Id: If25eae6507eebb7537eb8adbcbaa1fc1eec88f5c
2019-11-21Adjust byte order variable display/change if DW_AT_endianity is present.Peeter Joot3-0/+90
- Rationale: It is possible for compilers to indicate the desired byte order interpretation of scalar variables using the DWARF attribute: DW_AT_endianity A type flagged with this variable would typically use one of: DW_END_big DW_END_little which instructs the debugger what the desired byte order interpretation of the variable should be. The GCC compiler (as of V6) has a mechanism for setting the desired byte ordering of the fields within a structure or union. For, example, on a little endian target, a structure declared as: struct big { int v; short a[4]; } __attribute__( ( scalar_storage_order( "big-endian" ) ) ); could be used to ensure all the structure members have a big-endian interpretation (the compiler would automatically insert byte swap instructions before and after respective store and load instructions). - To reproduce GCC V8 is required to correctly emit DW_AT_endianity DWARF attributes in all situations when the scalar_storage_order attribute is used. A fix for (dwarf endianity instrumentation) for GCC V6-V7 can be found in the URL field of the following PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509 - Test-case: A new test case (testsuite/gdb.base/endianity.*) is included with this patch. Manual testing for mixed endianity code has also been done with GCC V8. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509#c4 - Observed vs. expected: Without this change, using scalar_storage_order that doesn't match the target, such as struct otherendian { int v; } __attribute__( ( scalar_storage_order( "big-endian" ) ) ); would behave like the following on a little endian target: Breakpoint 1 at 0x401135: file endianity.c, line 41. (gdb) run Starting program: /home/pjoot/freeware/t/a.out Missing separate debuginfos, use: debuginfo-install glibc-2.17-292.el7.x86_64 Breakpoint 1, main () at endianity.c:41 41 struct otherendian o = {3}; (gdb) n 43 do_nothing (&o); /* START */ (gdb) p o $1 = {v = 50331648} (gdb) p /x $2 = {v = 0x3000000} whereas with this gdb enhancement we can access the variable with the user specified endianity: Breakpoint 1, main () at endianity.c:41 41 struct otherendian o = {3}; (gdb) p o $1 = {v = 0} (gdb) n 43 do_nothing (&o); /* START */ (gdb) p o $2 = {v = 3} (gdb) p o.v = 4 $3 = 4 (gdb) p o.v $4 = 4 (gdb) x/4xb &o.v 0x7fffffffd90c: 0x00 0x00 0x00 0x04 (observe that the 4 byte int variable has a big endian representation in the hex dump.) gdb/ChangeLog 2019-11-21 Peeter Joot <peeter.joot@lzlabs.com> Byte reverse display of variables with DW_END_big, DW_END_little (DW_AT_endianity) dwarf attributes if different than the native byte order. * ada-lang.c (ada_value_binop): Use type_byte_order instead of gdbarch_byte_order. * ada-valprint.c (printstr): (ada_val_print_string): * ada-lang.c (value_pointer): (ada_value_binop): Use type_byte_order instead of gdbarch_byte_order. * c-lang.c (c_get_string): Use type_byte_order instead of gdbarch_byte_order. * c-valprint.c (c_val_print_array): Use type_byte_order instead of gdbarch_byte_order. * cp-valprint.c (cp_print_class_member): Use type_byte_order instead of gdbarch_byte_order. * dwarf2loc.c (rw_pieced_value): Use type_byte_order instead of gdbarch_byte_order. * dwarf2read.c (read_base_type): Handle DW_END_big, DW_END_little * f-lang.c (f_get_encoding): Use type_byte_order instead of gdbarch_byte_order. * findvar.c (default_read_var_value): Use type_byte_order instead of gdbarch_byte_order. * gdbtypes.c (check_types_equal): Require matching TYPE_ENDIANITY_NOT_DEFAULT if set. (recursive_dump_type): Print TYPE_ENDIANITY_BIG, and TYPE_ENDIANITY_LITTLE if set. (type_byte_order): new function. * gdbtypes.h (TYPE_ENDIANITY_NOT_DEFAULT): New macro. (struct main_type) <flag_endianity_not_default>: New field. (type_byte_order): New function. * infcmd.c (default_print_one_register_info): Use type_byte_order instead of gdbarch_byte_order. * p-lang.c (pascal_printstr): Use type_byte_order instead of gdbarch_byte_order. * p-valprint.c (pascal_val_print): Use type_byte_order instead of gdbarch_byte_order. * printcmd.c (print_scalar_formatted): Use type_byte_order instead of gdbarch_byte_order. * solib-darwin.c (darwin_current_sos): Use type_byte_order instead of gdbarch_byte_order. * solib-svr4.c (solib_svr4_r_ldsomap): Use type_byte_order instead of gdbarch_byte_order. * stap-probe.c (stap_modify_semaphore): Use type_byte_order instead of gdbarch_byte_order. * target-float.c (target_float_same_format_p): Use type_byte_order instead of gdbarch_byte_order. * valarith.c (scalar_binop): (value_bit_index): Use type_byte_order instead of gdbarch_byte_order. * valops.c (value_cast): Use type_byte_order instead of gdbarch_byte_order. * valprint.c (generic_emit_char): (generic_printstr): (val_print_string): Use type_byte_order instead of gdbarch_byte_order. * value.c (unpack_long): (unpack_bits_as_long): (unpack_value_bitfield): (modify_field): (pack_long): (pack_unsigned_long): Use type_byte_order instead of gdbarch_byte_order. * findvar.c (unsigned_pointer_to_address): (signed_pointer_to_address): (unsigned_address_to_pointer): (address_to_signed_pointer): (default_read_var_value): (default_value_from_register): Use type_byte_order instead of gdbarch_byte_order. * gnu-v3-abi.c (gnuv3_make_method_ptr): Use type_byte_order instead of gdbarch_byte_order. * riscv-tdep.c (riscv_print_one_register_info): Use type_byte_order instead of gdbarch_byte_order. gdb/testsuite/ChangeLog 2019-11-21 Peeter Joot <peeter.joot@lzlabs.com> * gdb.base/endianity.c: New test. * gdb.base/endianity.exp: New file. Change-Id: I4bd98c1b4508c2d7c5a5dbb15d7b7b1cb4e667e2
2019-11-21gdb/testsuite: skip gdb.arch/amd64-eval.exp when target is not x86_64Lukas Durfina2-0/+9
2019-11-21[gdb] Only force INTERP_CONSOLE ui_out for breakpoint commands in MI modeTom de Vries2-0/+26
The problem reported in PR mi/25055 is that the output of the backtrace command, when executed as breakpoint command does not show when executing using the MI interpreter: ... $ gdb a.out Reading symbols from a.out... (gdb) break main Breakpoint 1 at 0x4003c0: file test.c, line 19. (gdb) commands Type commands for breakpoint(s) 1, one per line. End with a line saying just "end". >bt >end (gdb) interpreter-exec mi "-exec-run" ^done Breakpoint 1, main () at test.c:19 19 return foo (4); (gdb) ... Interestingly, the function print_frame is called twice during -exec-run: - once during tui_on_normal_stop where the ui_out is temporarily set to tui->interp_ui_out (), resulting in the part after the comma in "Breakpoint 1, main () at test.c:19" - once during execute_control_command, where the ui_out is the default for the current interpreter: mi_ui_out, which ignores calls to output text. The commit 3a87ae656c2 "Use console uiout when executing breakpoint commands" fixes the problem by temporarily switching to the ui_out of INTERP_CONSOLE in execute_control_command. This however caused a regression in redirection (escaping '#' using '\' for git commit message convenience): ... $ rm -f gdb.txt; gdb a.out Reading symbols from a.out... (gdb) break main Breakpoint 1 at 0x4003c0: file test.c, line 19. (gdb) commands Type commands for breakpoint(s) 1, one per line. End with a line saying just "end". >bt >end (gdb) set logging redirect on (gdb) set logging on Redirecting output to gdb.txt. Copying debug output to gdb.txt. (gdb) run \#0 main () at test.c:19 (gdb) q A debugging session is active. Inferior 1 [process 22428] will be killed. Quit anyway? (y or n) y $ cat gdb.txt Starting program: /data/gdb_versions/devel/a.out Breakpoint 1, main () at test.c:19 19 return foo (4); ... The problem is that the '#0 main () at test.c:19' ends up in the gdb output output rather than in gdb.txt. This is due to the fact that the redirect is setup for the current ui_out (which is tui->interp_ui_out ()), while the backtrace output is printed to the INTERP_CONSOLE ui_out. Fix this by limiting switching to INTERP_CONSOLE ui_out to when INTERP_MI is active. Tested on x86_64-linux. gdb/ChangeLog: 2019-11-21 Tom de Vries <tdevries@suse.de> PR gdb/24956 * cli/cli-script.c (execute_control_command): Only switch to INTERP_CONSOLE's ui_out when INTERP_MI is active. gdb/testsuite/ChangeLog: 2019-11-21 Tom de Vries <tdevries@suse.de> PR gdb/24956 * gdb.base/ui-redirect.exp: Test output of user-defined command. Change-Id: Id1771e7fcc9496a7d97ec2b2ea6b1487596f1ef7
2019-11-20Add missing parentheses on 'print' (gdb.python/py-progspace.exp)Sergio Durigan Junior2-3/+8
Commit 33d569b709886a1208145806da80b689d9cae9da ("gdb/python: Return None from Progspace.block_for_pc on error") added a few tests on gdb.python/py-progspace.exp which use 'print', but forgot to use parentheses when passing the arguments to be printed. This fails on Python 3. This commit adds these missing parentheses. Pushed as obvious. gdb/testsuite/ChangeLog: 2019-11-20 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.python/py-progspace.exp: Add missing parentheses on some 'print' commands. Change-Id: Iac0a7578855d128bbee3b98e7ea5888dae55fc00
2019-11-19Fix the "winheight" commandTom Tromey2-0/+41
The "winheight" command is broken. I probably broke it in one of my TUI refactoring patches, though I didn't track down exactly which one. The bug is that the code does: *buf_ptr = '\0'; ... but then never advances buf_ptr past this point, so no window name is seen. This patch refactors the code a bit so that a copy of the argument string is not needed, also fixing the bug. A new test case is included. gdb/ChangeLog 2019-11-19 Tom Tromey <tom@tromey.com> * tui/tui-win.c (tui_partial_win_by_name): Move from tui-data.c. Now static. Change type of "name". (tui_set_win_height_command): Don't copy "arg". * tui/tui-data.h (tui_partial_win_by_name): Don't declare. * tui/tui-data.c (tui_partial_win_by_name): Move to tui-win.c. gdb/testsuite/ChangeLog 2019-11-19 Tom Tromey <tom@tromey.com> * gdb.tui/winheight.exp: New file. Change-Id: I0871e93777a70036dbec9c9543f862f42e3a81e5
generated by cgit v1.1 at 2025-02-10 05:30:30 +0000