aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2021-01-07Fix regression in Ada aggregate assignmentTom Tromey2-0/+7
A recent upstream patch of mine caused a regression in aggregate assignment. The bug was that add_component_interval didn't properly update the array contents in one resize case. I found furthermore that there was no test case that would provoke this failure. This patch fixes the bug and introduces a test. gdb/ChangeLog 2021-01-07 Tom Tromey <tromey@adacore.com> * ada-lang.c (add_component_interval): Start loop using vector's updated size. gdb/testsuite/ChangeLog 2021-01-07 Tom Tromey <tromey@adacore.com> * gdb.ada/assign_arr.exp: Add 'others' test.
2021-01-06Fix fixed-point binary operation type handlingTom Tromey4-0/+31
Testing showed that gdb was not correctly handling some fixed-point binary operations correctly. Addition and subtraction worked by casting the result to the type of left hand operand. So, "fixed+int" had a different type -- and different value -- from "int+fixed". Furthermore, for multiplication and division, it does not make sense to first cast both sides to the fixed-point type. For example, this can prevent "f * 1" from yielding "f", if 1 is not in the domain of "f". Instead, this patch changes gdb to use the value. (This is somewhat different from Ada semantics, as those can yield a "universal fixed point".) This includes a new test case. It is only run in "minimal" mode, as the old-style fixed point works differently, and is obsolete, so I have no plans to change it. gdb/ChangeLog 2021-01-06 Tom Tromey <tromey@adacore.com> * ada-lang.c (ada_evaluate_subexp) <BINOP_ADD, BINOP_SUB>: Do not cast result. * valarith.c (fixed_point_binop): Handle multiplication and division specially. * valops.c (value_to_gdb_mpq): New function. (value_cast_to_fixed_point): Use it. gdb/testsuite/ChangeLog 2021-01-06 Tom Tromey <tromey@adacore.com> * gdb.ada/fixed_points/pck.ads (Delta4): New constant. (FP4_Type): New type. (FP4_Var): New variable. * gdb.ada/fixed_points/fixed_points.adb: Update. * gdb.ada/fixed_points.exp: Add tests for binary operators.
2021-01-06gdb/testsuite: fix race in ↵Simon Marchi3-3/+28
gdb.threads/signal-while-stepping-over-bp-other-thread.exp Commit 3ec3145c5dd6 ("gdb: introduce scoped debug prints") updated some tests using "set debug infrun" to handle the fact that a debug print is now shown after the prompt, after an inferior stop. The same issue happens in gdb.threads/signal-while-stepping-over-bp-other-thread.exp. If I run it in a loop, it eventually fails like these other tests. The problem is that the testsuite expects to see $gdb_prompt followed by the end of the buffer. It happens that expect reads $gdb_prompt and the debug print at the same time, in which case the regexp never matches and we get a timeout. The fix is the same as was done in 3ec3145c5dd6, make the testsuite believe that the prompt is the standard GDB prompt followed by that debug print. Since that test uses gdb_test_sequence, and the expected prompt is in gdb_test_sequence, add a -prompt switch to gdb_test_sequence to override the prompt used for that call. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_test_sequence): Accept -prompt switch. * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Pass prompt containing debug print to gdb_test_sequence. Change-Id: I33161c53ddab45cdfeadfd50b964f8dc3caa9729
2021-01-04[gdb/symtab] Remove superfluous end-of-sequence markerTom de Vries2-0/+98
While working on PR26935 I noticed that when running test-case gdb.base/morestack.exp with target board unix/-m32/-fPIE/-pie and ld linker, I get this linetable fragment for morestack.S using readelf -wL: ... CU: ../../../../libgcc/config/i386/morestack.S: Line number Starting address View Stmt 109 0xc9c x ... 838 0xe03 x - 0xe04 636 0 x 637 0x3 x - 0x4 ... but with "maint info line-table" I get: ... INDEX LINE ADDRESS IS-STMT 0 END 0x00000004 Y 1 109 0x00000c9c Y ... 110 838 0x00000e03 Y 111 END 0x00000e04 Y ... So, apparently the entries with addresses 0x0 and 0x3 are filtered out because the addresses are out of range, but the same doesn't happen with the end-of-seq terminator. Fix this by filtering out end-of-seq terminators that do not actually terminate anything. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-04 Tom de Vries <tdevries@suse.de> * buildsym.c (buildsym_compunit::record_line): Filter out end-of-seq terminators that do not terminate anything. gdb/testsuite/ChangeLog: 2021-01-04 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: New file.
2021-01-04gdb: introduce scoped debug printsSimon Marchi5-10/+31
I spent a lot of time reading infrun debug logs recently, and I think they could be made much more readable by being indented, to clearly see what operation is done as part of what other operation. In the current format, there are no visual cues to tell where things start and end, it's just a big flat list. It's also difficult to understand what caused a given operation (e.g. a call to resume_1) to be done. To help with this, I propose to add the new scoped_debug_start_end structure, along with a bunch of macros to make it convenient to use. The idea of scoped_debug_start_end is simply to print a start and end message at construction and destruction. It also increments/decrements a depth counter in order to make debug statements printed during this range use some indentation. Some care is taken to handle the fact that debug can be turned on or off in the middle of such a range. For example, a "set debug foo 1" command in a breakpoint command, or a superior GDB manually changing the debug_foo variable. Two macros are added in gdbsupport/common-debug.h, which are helpers to define module-specific macros: - scoped_debug_start_end: takes a message that is printed both at construction / destruction, with "start: " and "end: " prefixes. - scoped_debug_enter_exit: prints hard-coded "enter" and "exit" messages, to denote the entry and exit of a function. I added some examples in the infrun module to give an idea of how it can be used and what the result looks like. The macros are in capital letters (INFRUN_SCOPED_DEBUG_START_END and INFRUN_SCOPED_DEBUG_ENTER_EXIT) to mimic the existing SCOPE_EXIT, but that can be changed if you prefer something else. Here's an excerpt of the debug statements printed when doing "continue", where a displaced step is started: [infrun] proceed: enter [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT [infrun] global_thread_step_over_chain_enqueue: enqueueing thread Thread 0x7ffff75a5640 (LWP 2289301) in global step over chain [infrun] start_step_over: enter [infrun] start_step_over: stealing global queue of threads to step, length = 1 [infrun] start_step_over: resuming [Thread 0x7ffff75a5640 (LWP 2289301)] for step-over [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [Thread 0x7ffff75a5640 (LWP 2289301)] at 0x5555555551bd [displaced] displaced_step_prepare_throw: displaced-stepping Thread 0x7ffff75a5640 (LWP 2289301) now [displaced] prepare: selected buffer at 0x5555555550c2 [displaced] prepare: saved 0x5555555550c2: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 [displaced] amd64_displaced_step_copy_insn: copy 0x5555555551bd->0x5555555550c2: c7 45 fc 00 00 00 00 eb 13 8b 05 d4 2e 00 00 83 [displaced] displaced_step_prepare_throw: prepared successfully thread=Thread 0x7ffff75a5640 (LWP 2289301), original_pc=0x5555555551bd, displaced_pc=0x5555555550c2 [displaced] resume_1: run 0x5555555550c2: c7 45 fc 00 [infrun] infrun_async: enable=1 [infrun] prepare_to_wait: prepare_to_wait [infrun] start_step_over: [Thread 0x7ffff75a5640 (LWP 2289301)] was resumed. [infrun] operator(): step-over queue now empty [infrun] start_step_over: exit [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop [infrun] proceed: resuming Thread 0x7ffff7da7740 (LWP 2289296) [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7da7740 (LWP 2289296)] at 0x7ffff7f7d9b7 [infrun] prepare_to_wait: prepare_to_wait [infrun] proceed: resuming Thread 0x7ffff7da6640 (LWP 2289300) [infrun] resume_1: thread Thread 0x7ffff7da6640 (LWP 2289300) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0). [infrun] prepare_to_wait: prepare_to_wait [infrun] proceed: [Thread 0x7ffff75a5640 (LWP 2289301)] resumed [infrun] proceed: resuming Thread 0x7ffff6da4640 (LWP 2289302) [infrun] resume_1: thread Thread 0x7ffff6da4640 (LWP 2289302) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0). [infrun] prepare_to_wait: prepare_to_wait [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop [infrun] proceed: exit We can easily see where the call to `proceed` starts and end. We can also see why there are a bunch of resume_1 calls, it's because we are resuming threads, emulating all-stop on top of a non-stop target. We also see that debug statements nest well with other modules that have been migrated to use the "new" debug statement helpers (because they all use debug_prefixed_vprintf in the end. I think this is desirable, for example we could see the debug statements about reading the DWARF info of a library nested under the debug statements about loading that library. Of course, modules that haven't been migrated to use the "new" helpers will still print without indentations. This will be one good reason to migrate them. I think the runtime cost (when debug statements are disabled) of this is reasonable, given the improvement in readability. There is the cost of the conditionals (like standard debug statements), one more condition (if (m_must_decrement_print_depth)) and the cost of constructing a stack object, which means copying a fews pointers. Adding the print in fetch_inferior_event breaks some tests that use "set debug infrun", because it prints a debug statement after the prompt. I adapted these tests to cope with it, by using the "-prompt" switch of gdb_test_multiple to as if this debug statement is part of the expected prompt. It's unfortunate that we have to do this, but I think the debug print is useful, and I don't want a few tests to get in the way of adding good debug output. gdbsupport/ChangeLog: * common-debug.h (debug_print_depth): New. (struct scoped_debug_start_end): New. (scoped_debug_start_end): New. (scoped_debug_enter_exit): New. * common-debug.cc (debug_prefixed_vprintf): Print indentation. gdb/ChangeLog: * debug.c (debug_print_depth): New. * infrun.h (INFRUN_SCOPED_DEBUG_START_END): New. (INFRUN_SCOPED_DEBUG_ENTER_EXIT): New. * infrun.c (start_step_over): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT. (proceed): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT and INFRUN_SCOPED_DEBUG_START_END. (fetch_inferior_event): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT. gdbserver/ChangeLog: * debug.cc (debug_print_depth): New. gdb/testsuite/ChangeLog: * gdb.base/ui-redirect.exp: Expect infrun debug print after prompt. * gdb.threads/ia64-sigill.exp: Likewise. * gdb.threads/watchthreads-reorder.exp: Likewise. Change-Id: I7c3805e6487807aa63a1bae318876a0c69dce949
2021-01-04gdb/testsuite: avoid reading files through the remote protocol in ↵Simon Marchi18-48/+208
gdb.server/*.exp When I run some tests in gdb.server (fox example gdb.server/ext-attach.exp) on Ubuntu 20.04 with separate debug info for glibc installed, they often time out. This is because GDB reads the debug info through the remote protocol which is particularly slow: attach 316937 Attaching to program: /home/smarchi/build/binutils-gdb-all-targets/gdb/testsuite/outputs/gdb.server/ext-attach/ext-attach, process 316937 Reading /lib/x86_64-linux-gnu/libc.so.6 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:/lib/x86_64-linux-gnu/libc.so.6... Reading /lib/x86_64-linux-gnu/libc-2.31.so from remote target... Reading /lib/x86_64-linux-gnu/.debug/libc-2.31.so from remote target... Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target... FAIL: gdb.server/ext-attach.exp: attach to remote program 1 (timeout) This is avoided in gdbserver boards by adding "set sysroot" to GDBFLAGS (see boards/local-board.exp), which makes GDB read files from the local filesystem. But gdb.server tests spawn GDBserver directly, so are ran even when using the default unix board, where the "set sysroot" isn't used. Modify these tests to append "set sysroot" to the GDBFLAGS, a bit like lib/local-board.exp does. One special case is gdb.server/sysroot.exp, whose intent is to test different "set sysroot" values. For this one, increase the timeout when testing the "target:" sysroot. gdb/testsuite/ChangeLog: * gdb.server/abspath.exp: Append "set sysroot" to GDBFLAGS. * gdb.server/connect-without-multi-process.exp: Likewise. * gdb.server/exit-multiple-threads.exp: Likewise. * gdb.server/ext-attach.exp: Likewise. * gdb.server/ext-restart.exp: Likewise. * gdb.server/ext-run.exp: Likewise. * gdb.server/ext-wrapper.exp: Likewise. * gdb.server/multi-ui-errors.exp: Likewise. * gdb.server/no-thread-db.exp: Likewise. * gdb.server/reconnect-ctrl-c.exp: Likewise. * gdb.server/run-without-local-binary.exp: Likewise. * gdb.server/server-kill.exp: Likewise. * gdb.server/server-run.exp: Likewise. * gdb.server/solib-list.exp: Likewise. * gdb.server/stop-reply-no-thread.exp: Likewise. * gdb.server/wrapper.exp: Likewise. * gdb.server/sysroot.exp: Increase timeout when testing the target: sysroot. Change-Id: I7451bcc737f90e2cd0b977e9f09da3710774b0bf
2021-01-04gdb/testsuite: use clean_restart in gdb.server/server-run.expSimon Marchi2-4/+5
I think this sequence of commands can be replaced with clean_restart. gdb/testsuite/ChangeLog: * gdb.server/server-run.exp: Use clean_restart. Change-Id: If8c3eaa89f4ee58901282f5f1d5d4e1100ce7ac5
2021-01-04gdb/testsuite: use clean_restart in gdb.server/ext-run.expSimon Marchi2-7/+7
I think the sequence of commands here could be replaced with clean_restart. The test starts with GDB not started, so it should not be started when we reach gdb_skip_xml_test. gdb/testsuite/ChangeLog: * gdb.server/ext-run.exp: Use clean_restart. Change-Id: I8c033bad6c52f3d58d6aa377b8355fc633c7aede
2021-01-04gdb/testsuite: use build_executable in gdb.server/stop-reply-no-thread.expSimon Marchi2-1/+6
This test uses prepare_for_testing, then does a clean_restart for each test configuration. prepare_for_testing does a build_executable plus a clean_restart. So the clean_restart inside prepare_for_testing is done for nothing. Change prepare_for_testing to just build_executable to avoid the unnecessary clean_restart. gdb/testsuite/ChangeLog: * gdb.server/stop-reply-no-thread.exp: Use build_executable instead of prepare_for_testing. Change-Id: I8b2a2e90353c57c39c49a3665083331b4882fdd0
2021-01-04gdb/testsuite: use clean_restart in gdb.server/solib-list.expSimon Marchi2-6/+5
I think this sequence of commands can be replaced by clean_restart, despite what the comment says, as long as we don't use the `binfile` argument to clean_restart. gdb/testsuite/ChangeLog: * gdb.server/solib-list.exp: Use clean_restart. Change-Id: I4930564c50a1865cbffe0d660a4296c9d2158084
2021-01-04[gdb/testsuite] Don't require gold for gdb.base/morestack.expTom de Vries3-11/+7
While working on PR26935 I noticed that the test-case requires the gold linker, but doesn't really need it. The -fuse-ld=gold was added to support the printf in the test-case, which prints some information but is not otherwise needed for the test-case. Fix this by removing the printf and the corresponding -fuse-ld=gold. Tested on x86_64-linux. Also checked that the test still fails when the fix from the commit that added the test-case is reverted. gdb/testsuite/ChangeLog: 2021-01-04 Tom de Vries <tdevries@suse.de> * gdb.base/morestack.c: Remove printf. * gdb.base/morestack.exp: Don't use -fuse-ld=gold.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker3962-3962/+3962
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-12-31Update gdb.rust tests for Rust 1.49Tom Tromey2-4/+14
Rust 1.49 was released today, and it includes some library changes which caused some gdb.rust tests to fail. This patch adapts the test suite to the new output. I also verified that this continues to work with Rust 1.48. gdb/testsuite/ChangeLog 2020-12-31 Tom Tromey <tom@tromey.com> * gdb.rust/simple.exp: Update output for Rust 1.49.
2020-12-31Fix passing debug options for gccBernd Edlinger2-1/+5
Fix a bug in the test where we were missing "additional_flags=", causing -gstatement-frontiers not to be passed to the compiler. The issue was introduced in eb24648c453c28f2898fb599311ba004394a8b41 ("Fix gdb.cp/step-and-next-inline.exp with Clang"). gdb/testsuite: 2020-12-31 Bernd Edlinger <bernd.edlinger@hotmail.de> * gdb.cp/step-and-next-inline.exp: Fix test case.
2020-12-30gdb/testsuite: de-duplicate test names in gdb.python/py-frame-args.expSimon Marchi2-22/+30
Use with_test_prefix to de-duplicate test names. gdb/testsuite/ChangeLog: * gdb.python/py-frame-args.exp: De-duplicate test names. Change-Id: I5cc8bee692a0d071cb78258aca80ea642e00e7a8
2020-12-24gdb: avoid resolving dynamic properties for non-allocated arraysAndrew Burgess3-0/+165
In PR gdb/27059 an issue was discovered where GDB would sometimes trigger undefined behaviour in the form of signed integer overflow. The problem here is that GDB was reading random garbage from the inferior memory space, assuming this data was valid, and performing arithmetic on it. This bug raises an interesting general problem with GDB's DWARF expression evaluator, which is this: We currently assume that the DWARF expressions being evaluated are well formed, and well behaving. As an example, this is the expression that the bug was running into problems on, this was used as the expression for a DW_AT_byte_stride of a DW_TAG_subrange_type: DW_OP_push_object_address; DW_OP_plus_uconst: 88; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_mul Two values are read from the inferior and multiplied together. GDB should not assume that any value read from the inferior is in any way sane, as such the implementation of DW_OP_mul should be guarding against overflow and doing something semi-sane here. However, it turns out that the original bug PR gdb/27059, is hitting a more specific case, which doesn't require changes to the DWARF expression evaluator, so I'm going to leave the above issue for another day. In the test mentioned in the bug GDB is actually trying to resolve the dynamic type of a Fortran array that is NOT allocated. A non-allocated Fortran array is one that does not have any data allocated for it yet, and even the upper and lower bounds of the array are not yet known. It turns out that, at least for gfortran compiled code, the data fields that describe the byte-stride are not initialised until the array is allocated. This leads me to the following conclusion: GDB should not try to resolve the bounds, or stride information for an array that is not allocated (or not associated, a similar, but slightly different Fortran feature). Instead, each of these properties should be set to undefined if the array is not allocated (or associated). That is what this commit does. There's a new flag that is passed around during the dynamic array resolution. When this flag is true the dynamic properties are resolved using the DWARF expressions as they currently are, but when this flag is false the expressions are not evaluated, and instead the properties are set to undefined. gdb/ChangeLog: PR gdb/27059 * eval.c (evaluate_subexp_for_sizeof): Handle not allocated and not associated arrays. * f-lang.c (fortran_adjust_dynamic_array_base_address_hack): Don't adjust arrays that are not allocated/associated. * gdbtypes.c (resolve_dynamic_range): Update header comment. Add new parameter which is used to sometimes set dynamic properties to undefined. (resolve_dynamic_array_or_string): Update header comment. Add new parameter which is used to guard evaluating dynamic properties. Resolve allocated/associated properties first. gdb/testsuite/ChangeLog: PR gdb/27059 * gdb.dwarf2/dyn-type-unallocated.c: New file. * gdb.dwarf2/dyn-type-unallocated.exp: New file.
2020-12-21Preserve gdb_std{out, err, log, targ, targerr} across interpreter_exec_cmdPeter Waller3-0/+73
Calls through interpreter_exec_cmd can cause the output state to be modified in a way which doesn't get back after the execution. It looks like the intent is that interp::resume should put things back how they should be, however, mi_interp::resume modifies gdb_stdout and nothing currently restores it to the previous state. To see the broken behaviour: gdb -ex starti -ex bt -ex 'interpreter-exec mi echo' -ex bt -ex q echo <<<'' Prior to this patch, on a terminal environment, the first backtrace is coloured, and the second backtrace is not. The reason is that stdio_file::can_emit_style_escape becomes false, because the gdb_stdout gets overwritten in mi_interp::resume and not replaced. gdb/ChangeLog: * interps.c (interpreter_exec_cmd): Restore streams pointers. gdb/testsuite/ChangeLog: * gdb.base/style-interp-exec-mi.exp: New. * gdb.base/style-interp-exec-mi.c: New. Signed-off-by: Peter Waller <p@pwaller.net> Change-Id: Id87423b262d058857ea9dca5866ca6471741e512
2020-12-21gdb/testsuite: use gdb_test in gdb.base/list.expSimon Marchi2-151/+35
Use gdb_test instead of send_gdb + gdb_expect. Use proc_with_prefix to help with name uniqueness. gdb/testsuite/ChangeLog: * gdb.base/list.exp: Replace send_gdb + gdb_expect with gdb_test. Use proc_with_prefix. Change-Id: Ieee8fb2c80f596f60397fab7633773a7f8c8c879
2020-12-21testsuite, gdb.btrace: fix 32-bit PIE false positivesMarkus Metzger4-5/+19
For 32-bit position independent executables, GCC generates an extra call to __x86.get_pc_thunk.<reg> which appears in the function call history. It is correct to appear there but this confuses the tests, which check for an expected sequence of functions. Build with nopie to avoid this complication. gdb/testsuite/ChangeLog: 2020-12-04 Markus Metzger <markus.t.metzger@intel.com> * gdb.btrace/exception.exp: Build with nopie. * gdb.btrace/function_call_history.exp: Likewise. * gdb.btrace/unknown_functions.exp: Likewise.
2020-12-21testsuite, gdb.btrace: skip multi-inferior.exp on gdbserver targetsMarkus Metzger2-0/+9
The gdb.btrace/multi-inferior.exp test creates multiple inferiors to check that recording is per-inferior. When run with the native-gdbserver board, this test hangs when trying to add the second inferior over the remote connection. Skip the test. Note that the test runs fine with the native-extended-gdbserver board file and we want to keep testing that configuration. gdb/testsuite/ChangeLog: 2020-12-11 Markus Metzger <markus.t.metzger@intel.com> * gdb.btrace/multi-inferior.exp: Skip if use_gdb_stub.
2020-12-21testsuite, gdb.python: make py-record-*.exp test names uniqueMarkus Metzger3-4/+15
gdb/testsuite/ChangeLog: 2020-12-14 Markus Metzger <markus.t.metzger@intel.com> * gdb.python/py-record-btrace.exp: Make test names unique. * gdb.python/py-record-full.exp: Likewise.
2020-12-21testsuite, gdb.btrace: make test names uniqueMarkus Metzger11-140/+231
gdb/testsuite/ChangeLog: 2020-12-04 Markus Metzger <markus.t.metzger@intel.com> * gdb.btrace/data.exp: Make test names unique. * gdb.btrace/delta.exp: Likewise. * gdb.btrace/enable.exp: Likewise. * gdb.btrace/function_call_history.exp: Likewise. * gdb.btrace/nohist.exp: Likewise. * gdb.btrace/non-stop.exp: Likewise. * gdb.btrace/rn-dl-bind.exp: Likewise. * gdb.btrace/step.exp: Likewise. * gdb.btrace/stepi.exp: Likewise. * gdb.btrace/tailcall.exp: Likewise.
2020-12-21gdb, record: rephrase the 'not recording' error messageMarkus Metzger6-10/+18
When trying to use one of the record commands without having enabled recording first, GDB gives the error message: (gdb) record function-call-history No record target is currently active. Use one of the "target record-<TAB><TAB>" commands first. In the record help, however, we say: (gdb) help record record, rec Start recording. List of record subcommands: record btrace, record b -- Start branch trace recording. record delete, record del, record d -- Delete the rest of execution log and start recording it anew. record full -- Start full execution recording. record function-call-history -- Prints the execution history at function granularity. record goto -- Restore the program to its state at instruction number N. record instruction-history -- Print disassembled instructions stored in the execution log. record save -- Save the execution log to a file. record stop, record s -- Stop the record/replay target. Change the above error message to (gdb) record function-call-history No recording is currently active. Use the "record full" or "record btrace" command first. to align with the help text. gdb/ChangeLog: 2020-12-03 Markus Metzger <markus.t.metzger@intel.com> * record.c (require_record_target): Rephrase error message. (info_record_command): Likewise. gdb/testsuite/ChangeLog: 2020-12-03 Markus Metzger <markus.t.metzger@intel.com> * gdb.btrace/enable.exp: Update error message. * gdb.btrace/multi-inferior.exp: Likewise. * gdb.btrace/reconnect.exp: Likewise. * gdb.python/py-record-btrace.exp: Likewise. * gdb.python/py-record-full.exp: Likewise.
2020-12-20[gdb/testsuite] Add save_target_board_infoTom de Vries2-19/+61
Add a proc save_target_board_info, similar to save_vars, such that we can do: ... save_target_board_info { multilib_flags } { global board set board [target_info name] unset_board_info multilib_flags set_board_info multilib_flags "$override_multilib_flags" ... } ... and use it in gdb_compile_shlib. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-20 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (save_target_board_info): New proc. (gdb_compile_shlib): Use save_target_board_info.
2020-12-19[gdb/testsuite] Introduce supports_scalar_storage_order_attributeTom de Vries4-4/+63
Introduce support test procs: - supports_scalar_storage_order_attribute, and - supports_gnuc and use them in test-case gdb.base/endianity.exp. Tested on x86_64-linux with gcc-7.5.0, gcc-4.8.5, and clang 10.0.1. gdb/testsuite/ChangeLog: 2020-12-19 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (supports_scalar_storage_order_attribute) (supports_gnuc): New proc. * gdb.base/endianity.exp: Define TEST_SSO. Eliminate test_compiler_info calls. Add unsupported message. * gdb.base/endianity.c: Use TEST_SSO.
2020-12-19Don't compare types of enum fieldsHannes Domani5-0/+111
Comparing types of enum fields results in a crash, because they don't have a type. It can be reproduced by comparing the types of 2 instances of the same enum type in different objects: enum.h: enum e { zero, one, }; enum-1.c: #include <enum.h> int func(); enum e e1; int main() { return e1 + func(); } enum-2.c: #include <enum.h> enum e e2; int func() { return e2; } $ gcc -g -oenum enum-1.c enum-2.c $ gdb -q enum.exe Reading symbols from enum.exe... (gdb) py print(gdb.parse_and_eval("e1").type==gdb.parse_and_eval("e2").type) Thread 1 received signal SIGSEGV, Segmentation fault. [Switching to Thread 6184.0x1cc4] check_typedef (type=0x0) at C:/src/repos/binutils-gdb.git/gdb/gdbtypes.c:2745 2745 while (type->code () == TYPE_CODE_TYPEDEF) gdb/ChangeLog: 2020-12-19 Hannes Domani <ssbssa@yahoo.de> PR exp/27070 * gdbtypes.c (check_types_equal): Don't compare types of enum fields. gdb/testsuite/ChangeLog: 2020-12-19 Hannes Domani <ssbssa@yahoo.de> PR exp/27070 * gdb.python/compare-enum-type-a.c: New test. * gdb.python/compare-enum-type-b.c: New test. * gdb.python/compare-enum-type.exp: New file. * gdb.python/compare-enum-type.h: New test.
2020-12-18Add address keyword to Value.format_stringHannes Domani2-0/+47
This makes it possible to disable the address in the result string: const char *str = "alpha"; (gdb) py print(gdb.parse_and_eval("str").format_string()) 0x404000 "alpha" (gdb) py print(gdb.parse_and_eval("str").format_string(address=False)) "alpha" gdb/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python/py-value.c (valpy_format_string): Implement address keyword. gdb/doc/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python.texi (Values From Inferior): Document the address keyword. gdb/testsuite/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * gdb.python/py-format-string.exp: Add tests for address keyword.
2020-12-18Fix accessing a method's fields from PythonHannes Domani2-0/+7
Considering this example: struct C { int func() { return 1; } } c; int main() { return c.func(); } Accessing the fields of C::func, when requesting the function by its type, works: (gdb) py print(gdb.parse_and_eval('C::func').type.fields()[0].type) C * const But when trying to do the same via a class instance, it fails: (gdb) py print(gdb.parse_and_eval('c')['func'].type.fields()[0].type) Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: Type is not a structure, union, enum, or function type. Error while executing Python code. The difference is that in the former the function type is TYPE_CODE_FUNC: (gdb) py print(gdb.parse_and_eval('C::func').type.code == gdb.TYPE_CODE_FUNC) True And in the latter the function type is TYPE_CODE_METHOD: (gdb) py print(gdb.parse_and_eval('c')['func'].type.code == gdb.TYPE_CODE_METHOD) True So this adds the functionality for TYPE_CODE_METHOD as well. gdb/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python/py-type.c (typy_get_composite): Add TYPE_CODE_METHOD. gdb/testsuite/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * gdb.python/py-type.exp: Add tests for TYPE_CODE_METHOD.
2020-12-18Run fixed_points.exp with -fgnat-encodings=minimalTom Tromey2-61/+78
This changes the test case gdb.ada/fixed_points.exp to also be run with -fgnat-encodings=minimal. This change pointed out that the test case had a few incorrect expected outputs; these are fixed as well. Note that the Overprecise_Object test only uses the non-legacy output with GCC trunk. gdb/testsuite/ChangeLog 2020-12-18 Tom Tromey <tromey@adacore.com> * gdb.ada/fixed_points.exp: Also run with -fgnat-encodings=minimal. Update expected output.
2020-12-16gdb/testsuite: make some tests in gdb.base enable non-stop using GDBFLAGSSimon Marchi5-13/+27
For the same reason as explained in commit 7cb2893dfab1 ("gdb/testsuite: gdb.mi/mi-nonstop-exit.exp: enable non-stop using GDBFLAGS"). Note that the use of set GDBFLAGS "$GDBFLAGS ..." instead of append GDBFLAGS "..." is intentional. "append" is silent when appending to a non-existent variable. So if this code if moved to a proc (as is the case already for step-sw-breakpoint-adjust-pc.exp) and we forget to add "global GDBFLAGS", the flag won't be added to the global GDBFLAGS, and we won't actually enable non-stop, and it might go unnoticed. Using the "set" version will turn into an error if we forget the "global". This makes these test work correctly with native-extended-gdbserver. Some of them were silently failing because we runto_main is silent when it fails. gdb/testsuite/ChangeLog: * gdb.base/async-shell.exp: Enable non-stop through GDBFLAGS. * gdb.base/continue-all-already-running.exp: Likewise. * gdb.base/moribund-step.exp: Likewise. * gdb.base/step-sw-breakpoint-adjust-pc.exp: Likewise. Change-Id: I19ef05d07a0ec4a9c9476af2ba6e1ea1159ee437
2020-12-16[gdb/testsuite] Fix prompt regexp in batch-preserve-term-settings.expTom de Vries2-1/+5
On openSUSE Leap 15.2, when running test-case gdb.base/batch-preserve-term-settings.exp I get: ... spawn /bin/sh^M PS1="gdb-subshell$ "^M sh-4.4$ PS1="gdb-subshell$ "^M gdb-subshell$ PASS: gdb.base/batch-preserve-term-settings.exp: batch run: \ spawn shell ... but on Ubuntu 18.04.5, I get instead: ... spawn /bin/sh^M PS1="gdb-subshell$ "^M $ gdb-subshell$ FAIL: gdb.base/batch-preserve-term-settings.exp: batch run: \ spawn shell (timeout) ... Fix this by making the regexp recognize the second pattern as well. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-16 Tom de Vries <tdevries@suse.de> * gdb.base/batch-preserve-term-settings.exp:
2020-12-16[gdb/testsuite] Fix shlib compilation with target board unix/-pie/-fPIETom de Vries2-1/+43
When running test-case gdb.base/info-shared.exp with target board unix/-pie/-fPIE, we run into: ... spawn -ignore SIGHUP gcc -fno-stack-protector \ outputs/gdb.base/info-shared/info-shared-solib1.c.o \ -fdiagnostics-color=never -fPIC -shared -Wl,-soname,info-shared-solib1.so \ -lm -fPIE -pie -o outputs/gdb.base/info-shared/info-shared-solib1.so^M ld: Scrt1.o: in function `_start':^M start.S:104: undefined reference to `main'^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 ... The intention of the -pie/-fPIE flags is to build and test PIE executables on platforms where that is not the default. However, the flags clash with the flags required to build shared libraries. Fix this by filtering out PIE-related flags out of the multilib_flags settings in compile_shared_lib. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-16 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_compile_shlib_1): Factor out of ... (gdb_compile_shlib): ... here. Filter out PIE-related flags.
2020-12-16Fix TBI handling for watchpointsLuis Machado3-11/+31
When inserting hw watchpoints, we take care of masking off the top byte of the address (and sign-extending it if needed). This guarantees we won't pass tagged addresses to the kernel via ptrace. However, from the kernel documentation on tagged pointers... "Non-zero tags are not preserved when delivering signals. This means that signal handlers in applications making use of tags cannot rely on the tag information for user virtual addresses being maintained for fields inside siginfo_t. One exception to this rule is for signals raised in response to watchpoint debug exceptions, where the tag information will be preserved." So the stopped data address after a hw watchpoint hit can be potentially tagged, and we don't handle this in GDB at the moment. This results in GDB missing a hw watchpoint hit and attempting to step over an unsteppable hw watchpoint, causing it to spin endlessly. The following patch fixes this by adjusting the stopped data address and adds some tests to expose the problem. gdb/ChangeLog: 2020-12-16 Luis Machado <luis.machado@linaro.org> * aarch64-linux-nat.c (aarch64_linux_nat_target::stopped_data_address): Handle the TBI. gdbserver/ChangeLog: 2020-12-16 Luis Machado <luis.machado@linaro.org> * linux-aarch64-low.cc (address_significant): New function. (aarch64_target::low_stopped_data_address): Handle the TBI. gdb/testsuite/ChangeLog: 2020-12-16 Luis Machado <luis.machado@linaro.org> * gdb.arch/aarch64-tagged-pointer.c (main): Add a few more pointer-based memory accesses. * gdb.arch/aarch64-tagged-pointer.exp: Exercise additional hw watchpoint cases.
2020-12-15gdb: multi-line support for "document" commandRae Kim2-0/+34
"document" command executed in python, gdb.execute("document <comname>\n...\nend\n"), will wait for user input. Python extension stops working from that point. multi-line suport was introduced in commit 56bcdbea2. But "document" support seem to be implemented. gdb/ChangeLog: 2020-12-02 Rae Kim <rae.kim@gmail.com> * cli/cli-script.c (do_document_command): Rename from document_command. Handle multi-line input. (multi_line_command_p): Handle document_control. (build_command_line): Likewise. (execute_control_command_1): Likewise. (process_next_line): Likewise. (document_command): Call do_document_command. * cli/cli-script.h (enum command_control_type): Add document_control. gdb/testsuite/ChangeLog: 2020-12-02 Rae Kim <rae.kim@gmail.com> * gdb.base/document.exp: New test. Change-Id: Ice262b980c05051de4c106af9f3fde5b2a6df6fe
2020-12-15Highlight deprecated commands using title styleTom Tromey2-0/+11
After Andrew's latest patch, I noticed that the deprecation warnings could use the (so-called) title style when printing command names. This patch implements this idea. gdb/ChangeLog 2020-12-15 Tom Tromey <tromey@adacore.com> * cli/cli-decode.c (deprecated_cmd_warning): Use title style for command names. gdb/testsuite/ChangeLog 2020-12-15 Tom Tromey <tromey@adacore.com> * gdb.base/style.exp: Add deprecation tests.
2020-12-15[gdb/testsuite] Handle PS1 quirk in gdb.base/multi-line-starts-subshell.expTom de Vries1-3/+3
On SLE-11, I run into: ... (gdb) if 1^M >shell HOME=/dev/null PS1="gdb-subshell$ " /bin/sh^M >end^M hostname:/dir> FAIL: gdb.base/multi-line-starts-subshell.exp: \ spawn subshell from multi-line (timeout) ... The problem is that the PS1 setting has no effect, due to a bug on older openSUSE/SLE version. The mechanism there is: - /etc/profile sets ENV=/etc/bash.bashrc - /bin/sh is started - /bin/sh executes ENV, in other words /etc/bash.bashrc - during the execution of /etc/bash.bashrc, PS1 is set unconditionally Fix this by setting PS1 after spawning the subshell. Tested on x86_64-linux. 2020-12-15 Tom de Vries <tdevries@suse.de> PR testsuite/26952 * gdb.base/multi-line-starts-subshell.exp: Set PS1 after spawning shell.
2020-12-14gdb/testsuite: fix typo in gdb_test_multiple docSimon Marchi2-1/+5
gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_test_multiple): Fix typo in doc. Change-Id: Ieb188b3382395ce951bfba5a5f25aaea0f89ebf9
2020-12-14Add form used for SPECIAL_expr as comment in testsuite Dwarf AssemblerMark Wielaard2-1/+16
Replace the "SPECIAL_expr" comment with either "DW_FORM_block" or "DW_FORM_exprloc" in the abbrev. gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf::_handle_attribute): Handle SPECIAL_expr specially, set attr_form_comment to the actual FORM string used.
2020-12-14Use DW_FORM_exprloc in testsuite Dwarf Assembler for DWARF version 4+.Mark Wielaard2-5/+16
Since DWARF version 4 expressions are represented by DW_FORM_exprloc instead of a block form. Support this in the testsuite Dwarf Assembler by setting the SPECIAL_expr form once we know the CU version. This doesn't change any testsuite results, it just makes the produced DWARF valid. gdb also accepts expressions in block form for DWARF version 4 and above, but this is technically incorrect. gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf::_read_constants): Don't set _constants(SPECIAL_expr) here, but set it... (Dwarf::cu): ...here based on _cu_version.
2020-12-14[gdb/testsuite] Don't pass -fPIC to gdb_compile_shlibTom de Vries12-23/+38
When running test-case gdb.base/info-shared.exp, I see in gdb.log: ... Executing on host: \ gcc ... -fPIC -fpic -c -o info-shared-solib1.c.o info-shared-solib1.c ... The -fPIC comes from the test-case: ... if { [gdb_compile_shlib $srcfile_lib1 $binfile_lib1 \ [list additional_flags=-fPIC]] != "" } { ... but the -fpic, which overrides the -fPIC comes from gdb_compile_shlib. The proc gdb_compile_shlib adds the -fpic or similar dependent on platform and compiler. However, in some cases it doesn't add anything, which is probably why all those test-case pass -fPIC. Fix this by removing -fPIC from all the calls to gdb_compile_shlib, and ensuring that gdb_compile_shlib takes care of adding it, if required. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-14 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_compile_shlib): Make sure it's not necessary to pass -fPIC. * gdb.ada/catch_ex_std.exp: Don't pass -fPIC to gdb_compile_shlib. * gdb.base/break-probes.exp: Same. * gdb.base/ctxobj.exp: Same. * gdb.base/dso2dso.exp: Same. * gdb.base/global-var-nested-by-dso.exp: Same. * gdb.base/info-shared.exp: Same. * gdb.base/jit-reader-simple.exp: Same. * gdb.base/print-file-var.exp: Same. * gdb.base/skip-solib.exp: Same. * gdb.btrace/dlopen.exp: Same.
2020-12-14[gdb/testsuite] Handle missing xz in gdb.base/gnu-debugdata.expTom de Vries2-1/+10
When running test-case gdb.base/gnu-debugdata.exp on SLE-11, I run into: ... FAIL: gdb.base/gnu-debugdata.exp: xz ... The fact that xz is not installed does not mean there's a fail, merely that the test is unsupported. Fix this by detecting the "spawn failed" reply in run_on_host and issuing UNSUPPORTED instead. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-14 Tom de Vries <tdevries@suse.de> PR testsuite/26963 * lib/gdb.exp (run_on_host): Declare test unsupported if spawn fails.
2020-12-14[gdb/testsuite] Handle no glibc debuginfo in gdb.base/solib-corrupted.expTom de Vries2-1/+17
When running test-case gdb.base/solib-corrupted.exp on SLE-11, I get: ... (gdb) PASS: gdb.base/solib-corrupted.exp: normal list p/x _r_debug->r_map->l_next = _r_debug->r_map^M '_r_debug' has unknown type; cast it to its declared type^M (gdb) FAIL: gdb.base/solib-corrupted.exp: make solibs looping ... The reason that _r_debug has unknown type is that glibc debuginfo is not installed. The test-case attempts to detect this but doesn't handle this particular error string. Fix this by adding the "unknown type" line to the regexp detecting missing glibc debuginfo. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-14 Tom de Vries <tdevries@suse.de> PR testsuite/26962 * gdb.base/solib-corrupted.exp: Handle "'_r_debug' has unknown type; cast it to its declared type".
2020-12-14[gdb/testsuite] Handle shell prompt in batch-preserve-term-settings.expTom de Vries2-3/+12
On SLE-11, I run into: ... FAIL: gdb.base/batch-preserve-term-settings.exp: batch run: spawn shell \ (timeout) ... The problem is that the shell prompt has PS1="\h:\w> ", but the test expects a shell prompt ending in a space preceded by either '$' or '#': ... set shell_prompt_re "\[$#\] " ... We could easily fix this by adding '>' to shell_prompt_re, but this wouldn't work for other PS1 setting. Fix this instead by setting the shell prompt to "gdb-subshell$ " (as in gdb.base/multi-line-starts-subshell.exp). Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-14 Tom de Vries <tdevries@suse.de> PR testsuite/26951 * gdb.base/batch-preserve-term-settings.exp: Use "gdb-subshell$ " as shell prompt.
2020-12-14Handle block-local names for AdaTom Tromey3-2/+36
GNAT can generate a mangled name with "B_N" (where N is a number) in the middle, like "hello__B_1__fourth.0". This is used for names local to a block. Multiple levels of block-local name can also occur, a possibility that was neglected by v1 of this patch. This patch changes gdb to handle these names. The wild name matcher is updated a straightforward way. The full matcher is rewritten. The hash function is updated to ensure that this works. This version does not seem to have the performance problems that affected v1. In particular, the previously-slow "bt" problem has been fixed. gdb/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * dictionary.c (language_defn::search_name_hash): Ignore "B". * ada-lang.c (advance_wild_match): Ignore "B". (full_match): Remove. (do_full_match): Rewrite. gdb/testsuite/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * gdb.ada/nested.exp: Add new tests. * gdb.ada/nested/hello.adb (Fourth, Fifth): New procedures.
2020-12-14Be more careful when rewriting thick pointer array typeTom Tromey2-0/+99
To handle thick pointers with -fgnat-encodings=minimal, gdb will rewrite the underlying array type to remove the bounds. However, if the same DWARF type is used both for a thick pointer and for an ordinary array, this will have the side effect of removing the bounds from the array. This breaks the printing of objects of this type. This patch fixes the problem by copying the array type, its range, and its bounds. gdb/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (rewrite_array_type): New function. (quirk_ada_thick_pointer_struct): Use rewrite_array_type. gdb/testsuite/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/ada-thick-pointer.exp: New file.
2020-12-14Handle fixed-point division by zeroTom Tromey2-0/+7
fixed_point_binop did not account for division by zero. This would lead to gdb getting SIGFPE and subsequently cause some test cases to hang. gdb/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * valarith.c (fixed_point_binop): Call error on division by zero. gdb/testsuite/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/dw2-fixed-point.exp: Add test for division by zero.
2020-12-13[gdb/testsuite] Fix gdb.base/endianity.exp with gcc-4.8Tom de Vries2-4/+13
When running test-case gdb.base/endianity.exp using gcc-4.8, we get: ... (gdb) x/x &o.v^M 0x7fffffffd120: 0x00000004^M (gdb) XFAIL: gdb.base/endianity.exp: x/x &o.v x/xh &o.w^M 0x7fffffffd124: 0x0003^M (gdb) FAIL: gdb.base/endianity.exp: x/xh &o.w ... The gcc 4.8 compiler does not support the scalar_storage_order attribute, so the testcase is compiled without that attribute, and the expected results are different. Fix this by rather than xfailing, skipping the tests if the compiler does not support the scalar_storage_order attribute. Tested on x86_64-linux, with gcc-4.8, gcc-7, and clang-10. gdb/testsuite/ChangeLog: 2020-12-13 Tom de Vries <tdevries@suse.de> PR testsuite/26953 * gdb.base/endianity.exp: Skip tests requiring scalar_storage_order attribute support if compiler doesn't support it.
2020-12-13[gdb/testsuite] Handle ada in gdb_compile_shlibTom de Vries3-23/+45
The single test-case in the testsuite that creates an ada shared library is gdb.ada/catch_ex_std.exp. The test-case does use gdb_compile_shlib, but with a few tweaks that make sure things are properly handled for ada. Move the ada-specific code to gdb_compile_shlib, such that gdb_compile_sh can be used for ada shared libs without tweaks. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-13 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_compile_shlib): Handle ada. * gdb.ada/catch_ex_std.exp: Use gdb_compile_shlib to compile from source to shared lib. Add ada to options.
2020-12-13[gdb/testsuite] Avoid gnatbind/gnatlink in gdb.ada/catch_ex_std.expTom de Vries2-48/+28
There's a single test-case in the testsuite that explicitly calls gnatbind and gnatlink: gdb.ada/catch_ex_std.exp. Instead, use gnatmake and pass specific gnatbind and gnatlink options using gnatmake passthrough options -bargs and -largs. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-13 Tom de Vries <tdevries@suse.de> * gdb.ada/catch_ex_std.exp: Use gnatmake -bargs and -largs instead of calling gnatbind and gnatlink.
2020-12-13gdb: new command 'maint flush dcache'Andrew Burgess3-0/+102
Add a new command to flush the dcache. gdb/ChangeLog: * NEWS: Mention new commands. * target-dcache.c: Add 'cli/cli-cmds.h' include. (maint_flush_dcache_command): New function. (_initialize_target_dcache): Create new 'maint flush dcache' command. gdb/doc/ChangeLog: * gdb.texinfo (Caching Target Data): Document 'maint flush dcache'. gdb/testsuite/ChangeLog: * gdb.base/dcache-flush.c: New file. * gdb.base/dcache-flush.exp: New file.
generated by cgit v1.1 at 2025-02-27 05:00:39 +0000