aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2023-01-26Use clean_restart in gdb.openclTom Tromey1-6/+1
Change gdb.opencl to use clean_restart more consistently.
2023-01-26Use clean_restart in gdb.linespecTom Tromey1-3/+1
Change gdb.linespec to use clean_restart more consistently.
2023-01-26Use clean_restart in gdb.pascalTom Tromey2-10/+2
Change gdb.pascal to use clean_restart more consistently.
2023-01-26Use mi_clean_restart moreTom Tromey60-401/+147
This changes a number of MI tests to use mi_clean_restart rather than separate calls. This reduces the number of lines, which is nice, and also provides a nicer model to copy for future tests.
2023-01-26Start gdb after building executable in mi-basics.expTom Tromey1-5/+5
A lot of the MI tests start gdb and only then build the executable. This just seemed weird to me, so I've fixed this up. In this patch, no other cleanups are done, the startup is just moved to a more logical (to me) spot.
2023-01-26Remove unnecessary call to standard_testfileTom Tromey1-2/+0
This test does not build a program and does not need to call standard_testfile.
2023-01-26Minor "require" fixupsTom Tromey2-6/+2
I found a couple of spots that could use "require", and one spot where hoisting the "require" closer to the top of the file made it more clear.
2023-01-26Remove some dead code in gdb.fortran/info-types.expTom Tromey1-17/+0
An early "return" in this test case prevents a test from running. This seems to have been intentional and has been in place since: commit d57cbee932f86df06251498daa93154046dc77c0 Author: Andrew Burgess <andrew.burgess@embecosm.com> Date: Tue Dec 3 13:18:43 2019 +0000 gdb/testsuite/fortran: Fix info-modules/info-types for gfortran 8+ This patch removes the dead code.
2023-01-26Eliminate spurious returns from the test suiteTom Tromey113-173/+1
A number of tests end with "return". However, this is unnecessary. This patch removes all of these.
2023-01-26Use clean_restart in gdb.dlangTom Tromey4-16/+4
Change gdb.dlang to use clean_restart more consistently.
2023-01-26Use ordinary calling convention for clean_restartTom Tromey2-16/+6
clean_restart accepts a single optional argument. Rather than using {args} and handling the argument by hand, change it to use Tcl's own argument-checking.
2023-01-26gdb/testsuite: initialize "correct" variable in gdb.cp/cpexprs.exp.tclSimon Marchi1-0/+2
Due to a GDB bug (visible when building with -D_GLIBCXX_DEBUG), GDB crashes somewhere in the middle of gdb.cp/cpexprs.exp, and thus fails to read the string, at gdb.cp/cpexprs.exp.tcl:725. The "correct" variable doesn't get set, and I then see this TCL error: ERROR: can't read "correct": no such variable Avoid the TCL error by initializing the "correct" variable to a dummy value. Change-Id: I828968d9b2d105ef47f8da2ef598aa16a518c059
2023-01-26gdb/testsuite/dap: fix gdb.dap/basic-dap.exp disassembly test for PIESimon Marchi1-3/+30
Prior to this patch, I get: >>> {"seq": 17, "type": "request", "command": "disassemble", "arguments": {"memoryReference": "0x115d", "instructionCount": 1}} Content-Length: 147 {"request_seq": 17, "type": "response", "command": "disassemble", "success": false, "message": "Cannot access memory at address 0x115d", "seq": 41}FAIL: gdb.dap/basic-dap.exp: disassemble one instruction success FAIL: gdb.dap/basic-dap.exp: instructions in disassemble output The problem is that the PC to disassemble is taken from the breakpoint insertion response, which happens before running. With a PIE executable, that PC is unrelocated, but the disassembly request happens after relocation. I chose to fix this by watching for a breakpoint changed event giving the new breakpoint address, and recording the address from there. I think this is an interesting way to fix it, because it adds a bit of test coverage, I don't think these events are checked right now. Other ways to fix it would be: - Get the address by doing a breakpoint insertion after the program is started, or some other way. - Do the disassembly by symbol instead of by address. - Do the disassembly before running the program. Change-Id: I3c396f796ac4c8b22e7dfd2fa1c5467f7a47e84e
2023-01-26gdb/testsuite/dap: make dap_wait_for_event_and_check return preceding messagesSimon Marchi1-6/+22
In the following patch, I change gdb.dap/basic-dap.exp such that after waiting for some event, it checks if it received another event meanwhile. To help with this, make dap_wait_for_event_and_check and _dap_dap_wait_for_event return a list with everything received before the event of interest. This is similar to what dap_check_request_and_response returns. Change-Id: I85c8980203a2dec833937e7552c2196bc137935d
2023-01-26gdb/testsuite/dap: rename dap_read_event to dap_wait_for_event_and_checkSimon Marchi2-8/+8
I think that name describes a bit better what the proc does, it is similar to "wait_for" in tuiterm.exp. Change-Id: Ie55aa011e6595dd1b5a874db13881ba572ace419
2023-01-26gdb/testsuite/dap: pass around dicts instead of TON objectsSimon Marchi2-33/+30
The DAP helper functions generally return TON objects. However, callers almost all immediately use ton::2dict to convert them to dicts, to access their contents. This commits makes things a bit simpler for them by having function return dicts directly instead. The downside is that the TON objects contain type information. For instance, a "2" in a TCL dict could have been the integer 2 or the string "2" in JSON. By converting to TCL dicts, we lose that information. If some tests specifically want to check the types of some fields, I think we can add intermediary functions that return TON objects, without having to complicate other callers who don't care. Change-Id: I2ca47bea355bf459090bae8680c6a917350b5c3f
2023-01-26gdb/testsuite/dap: remove catch from dap_read_eventSimon Marchi1-5/+1
This catch didn't cause me any trouble, but for the same reason as the preceding patch, I think it's a bit better to just let any exception propagate, to make for easier debugging. Change-Id: I1779e62c788b77fef2d50434edf4c3d2ec5e1c4c
2023-01-26gdb/testsuite/dap: make dap_request_and_response not catch / issue test resultSimon Marchi2-20/+7
Following some of my changes, dap_request_and_response was failing and I didn't know why. I think it's better to make it not catch any exception, and just make it do a simple "send request, read response". If an exception is thrown while sending a request or reading a response, things are going really badly, it's not like we'll want to recover from that and continue the test. Change-Id: I27568d3547f753c3a74e3e5a730d38a8caef9356
2023-01-26gdb/testsuite/dap: write requests to gdb.logSimon Marchi1-1/+1
This helps following what happens when reading gdb.log. The downside is that it becomes harder to tell what text is from GDB and what text is going to GDB, but I think that seeing responses without seeing requests is even more confusing. At least, the lines are prefix with >>>, so when you see this, you know that until the end of the line, it's something that was sent to GDB, and not GDB output. Change-Id: I1ba1acd8b16f4e64686c5ad268cc41082951c874
2023-01-26gdb/testsuite/dap: prefix some procs with _Simon Marchi1-12/+12
Prefix some procs that are only used internally with an underscore, to make it clear they are internal. If they need to be used by some test later, we can always un-prefix them. Change-Id: Iacb8e77363b5d1f8b98d9ba5a6d115aee5c8925d
2023-01-26gdb/testsuite/dap: use gdb_assert in gdb.dap/basic-dap.expSimon Marchi1-16/+3
Use gdb_assert instead of manual pass/fail. Change-Id: I71fbc4e37a0a1ef4783056c7424e932651fa397f
2023-01-26[gdb/testsuite] Add gdb.base/unwind-on-each-insn-{amd64,i386}.expTom de Vries6-153/+792
The gcc 4.4.x (and earlier) compilers had the problem that the unwind info in the epilogue was inaccurate. In order to work around this in gdb, epilogue unwinders were added with a higher priority than the dwarf unwinders in the amd64 and i386 targets: - amd64_epilogue_frame_unwind, and - i386_epilogue_frame_unwind. Subsequently, the epilogue unwind info problem got fixed in gcc 4.5.0. However, the epilogue unwinders prevented gdb from taking advantage of the fixed epilogue unwind info, so the scope of the epilogue unwinders was limited, bailing out for gcc >= 4.5.0. There was no regression test added for this preference scheme, so if we now declare epilogue unwind info from all gcc versions as trusted, no test will start failing. Fix this by adding an amd64 and i386 regression test for this. I have no gcc 4.4.x lying around, so I fabricated the assembly files by: - commenting out some .cfi directives to break the epilogue unwind info, and - hand-editing the producer info to 4.4.7 to activate the fix. Tested on x86_64-linux, target boards unix/{-m64,-m32}.
2023-01-26[gdb/testsuite] Add and use is_x86_64_m64_targetTom de Vries54-114/+68
Add new proc is_x86_64_m64_target and use it where appropriate. Tested on x86_64-linux.
2023-01-25gdb/arm: Use new dwarf2 function cacheTorbjörn SVENSSON1-32/+65
This patch resolves the performance issue reported in pr/29738 by caching the values for the stack pointers for the inner frame. By doing so, the impact can be reduced to checking the state and returning the appropriate value. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
2023-01-25gdb: dwarf2 generic implementation for caching function dataTorbjörn SVENSSON2-2/+95
When there is no dwarf2 data for a register, a function can be called to provide the value of this register. In some situations, it might not be trivial to determine the value to return and it would cause a performance bottleneck to do the computation each time. This patch allows the called function to have a "cache" object that it can use to store some metadata between calls to reduce the performance impact of the complex logic. The cache object is unique for each function and frame, so if there are more than one function pointer stored in the dwarf2_frame_cache->reg array, then the appropriate pointer will be supplied (the type is not known by the dwarf2 implementation). dwarf2_frame_get_fn_data can be used to retrieve the function unique cache object. dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the function unique cache object. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
2023-01-25Clean up unusual code in mi-cmd-stack.cTom Tromey1-7/+9
I noticed some unusual code in mi-cmd-stack.c. This code is a switch, where one of the cases appears in the middle of another block. It seemed cleaner to me to have the earlier case just conditionally fall through.
2023-01-25Move target check into allow_altivec_testsTom Tromey4-3/+6
Pedro pointed out that only PPC can possibly have altivec, so we can move the target check into allow_altivec_tests.
2023-01-25Use require with is_remoteTom Tromey43-156/+64
This changes some tests to use require with 'is_remote', rather than an explicit test. This adds uniformity helps clean up more spots where a test might exit early without any notification.
2023-01-25Add unsupported calls where neededTom Tromey8-2/+9
A number of tests will exit early without saying why. This patch adds "unsupported" at spots like this that I could readily find. There are definitely more of these; for example dw2-ranges.exp fails silently because a compilation fails. I didn't attempt to address these as that is a much larger task.
2023-01-25Introduce and use is_any_targetTom Tromey28-110/+39
A few tests work on two different targets that can't be detected with a single call to istarget -- that proc only accepts globs, not regular expressions. This patch introduces a new is_any_target proc and then converts these tests to use it in a 'require'.
2023-01-25Use require with istargetTom Tromey125-549/+139
This changes many tests to use require when checking 'istarget'. A few of these conversions were already done in earlier patches. No change was needed to 'require' to make this work, due to the way it is written. I think the result looks pretty clear, and it has the bonus of helping to ensure that the reason that a test is skipped is always logged.
2023-01-25Rename skip_vsx_tests to allow formTom Tromey4-18/+20
This renames skip_vsx_tests to allow_vsx_tests and updates it users to use require.
2023-01-25Rename skip_power_isa_3_1_tests to allow formTom Tromey3-11/+13
This renames skip_power_isa_3_1_tests to allow_power_isa_3_1_tests and updates its users to use require.
2023-01-25Rename skip_float_test to allow formTom Tromey15-57/+51
This renames skip_float_test to allow_float_test and updates its users to use require.
2023-01-25Convert skip_altivec_tests to allow formTom Tromey4-18/+20
This renames skip_altivec_tests to allow_altivec_tests and updates its users to use require.
2023-01-25[gdb/testsuite] Fix gdb.base/unwind-on-each-insn.exp for -m32Tom de Vries1-1/+1
With test-case gdb.base/unwind-on-each-insn.exp and target board unix/-m32, I now get: ... # of expected passes 25 ... instead of: ... # of expected passes 133 ... as I used to get before commit d25a8dbc7c3 ("[gdb/testsuite] Allow debug srcfile2 in gdb.base/unwind-on-each-insn.exp"), due to the test-case trying to match "rip = " and info frame printing "eip = " instead. Fix this by dropping "rip" from the regexp. Tested on x86_64-linux, target boards unix/{-m64,-m32}.
2023-01-25[gdb/testsuite] Allow debug srcfile2 in gdb.base/unwind-on-each-insn.expTom de Vries1-2/+4
Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and $srcfile2 without. Occasionally, I try both files with debug info: ... - $srcfile $debug_flags $srcfile2 $nodebug_flags]]} { + $srcfile $debug_flags $srcfile2 $debug_flags]]} { ... This shortcuts the test due to no longer recognizing that stepi still lands in foo. Fix this by determining whether still in foo by checking the info frame output. Tested on x86_64-linux.
2023-01-25[gdb/testsuite] Allow nodebug srcfile in gdb.base/unwind-on-each-insn.expTom de Vries1-2/+2
Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and $srcfile2 without. Occasionally, I try both files with debug info: ... - $srcfile $debug_flags $srcfile2 $nodebug_flags]]} { + $srcfile $debug_flags $srcfile2 $debug_flags]]} { ... and both files without: ... - $srcfile $debug_flags $srcfile2 $nodebug_flags]]} { + $srcfile $nodebug_flags $srcfile2 $nodebug_flags]]} { ... In the latter case, I run into: ... FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: bt 2 FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: up ... due to a mismatch between the regexp and the different output due to using nodebug. Fix this by making the regexp less strict. Tested on x86_64-linux.
2023-01-25gdb, i386: Update stale comment in i386-tdep.h.Felix Willgerodt1-1/+1
The comment seems no longer valid, the functions technically check for non-pseudo registers, like zmmh. Which is a valid use case.
2023-01-25[gdb/testsuite] Analyze non-leaf fn in gdb.base/unwind-on-each-insn.expTom de Vries3-59/+86
In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo to check various invariants at each insn, in particular hoping to excercise insns that modify stack and frame pointers. Function foo is a leaf function, so add a non-leaf function bar, and step through it as well (using nexti instead of stepi). With the updated test-case, on powerpc64le-linux, I run into PR tdep/30049: ... FAIL: bar: instruction 5: bt 2 FAIL: bar: instruction 5: up FAIL: bar: instruction 5: [string equal $fid $::main_fid] FAIL: bar: instruction 6: bt 2 FAIL: bar: instruction 6: up FAIL: bar: instruction 6: [string equal $fid $::main_fid] ... Tested on: - x86_64-linux (-m64 and -m32) - s390x-linux (-m64 and -m31) - aarch64-linux - powerpc64le-linux
2023-01-25[gdb/testsuite] Improve leaf fn in gdb.base/unwind-on-each-insn.expTom de Vries3-4/+9
In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo to check various invariants at each insn, in particular hoping to excercise insns that modify stack and frame pointers. For x86_64-linux, we have a reasonably complex foo (and similar for -m32): ... 4004bc: 55 push %rbp 4004bd: 48 89 e5 mov %rsp,%rbp 4004c0: 90 nop 4004c1: 5d pop %rbp 4004c2: c3 ret ... Both stack pointer (%rsp) and frame pointer (%rbp) are modified. Also for s390x-linux (and similar for -m31): ... 0000000001000668 <foo>: 1000668: e3 b0 f0 58 00 24 stg %r11,88(%r15) 100066e: b9 04 00 bf lgr %r11,%r15 1000672: e3 b0 b0 58 00 04 lg %r11,88(%r11) 1000678: 07 fe br %r14 ... Frame pointer (%r11) is modified. Likewise for powerpc64le-linux: ... 00000000100006c8 <foo>: 100006c8: f8 ff e1 fb std r31,-8(r1) 100006cc: d1 ff 21 f8 stdu r1,-48(r1) 100006d0: 78 0b 3f 7c mr r31,r1 100006d4: 00 00 00 60 nop 100006d8: 30 00 3f 38 addi r1,r31,48 100006dc: f8 ff e1 eb ld r31,-8(r1) 100006e0: 20 00 80 4e blr ... Both stack pointer (r1) and frame pointer (r31) are modified. But for aarch64-linux, we have: ... 00000000004005fc <foo>: 4005fc: d503201f nop 400600: d65f03c0 ret ... There's no insn that modifies stack or frame pointer. Fix this by making foo more complex, adding an (unused) argument: ... 0000000000400604 <foo>: 400604: d10043ff sub sp, sp, #0x10 400608: f90007e0 str x0, [sp, #8] 40060c: d503201f nop 400610: 910043ff add sp, sp, #0x10 400614: d65f03c0 ret ... such that the stack pointer (sp) is modified. [ Note btw that we're seeing the effects of -momit-leaf-frame-pointer, with -mno-omit-leaf-frame-pointer we have instead: ... 0000000000400604 <foo>: 400604: a9be7bfd stp x29, x30, [sp, #-32]! 400608: 910003fd mov x29, sp 40060c: f9000fa0 str x0, [x29, #24] 400610: d503201f nop 400614: a8c27bfd ldp x29, x30, [sp], #32 400618: d65f03c0 ret ... such that also the frame pointer (x29) is modified. ] Having made foo more complex, we now run into the following fail on x86_64/-m32: ... FAIL: gdb.base/unwind-on-each-insn.exp: instruction 1: $sp_value == $main_sp .... The problem is that the stack pointer has changed inbetween the sampling of main_sp and *foo, in particular by the push insn: ... 804841a: 68 c0 84 04 08 push $0x80484c0 804841f: e8 10 00 00 00 call 8048434 <foo> ... Fix this by updating main_sp. On powerpc64le-linux, with gcc 7.5.0 I now run into PR tdep/30021: ... FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: $fba_value == $main_fba FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: [string equal $fid $main_fid] ... but I saw the same failure before this commit with gcc 4.8.5. Tested on: - x86_64-linux (-m64 and -m32) - s390x-linux (-m64 and -m31) - powerpc64le-linux - aarch64-linux Also I've checked that the test-case still functions as regression test for PR record/16678 on x86_64.
2023-01-25gdb/tui: make use of a scoped_restoreAndrew Burgess1-7/+3
Make use of a scoped_restore object in tui_mld_read_key instead of doing a manual save/restore. I don't think the existing code can throw an exception, so this is just a cleanup rather than a bug fix. There should be no user visible changes after this commit.
2023-01-25gdb/tui: better filtering of tab completion results for focus commandAndrew Burgess2-9/+33
While working on the previous couple of commits, I noticed that the 'focus' command would happily suggest 'status' as a possible focus completion, even though the 'status' window is non-focusable, and, after the previous couple of commits, trying to focus the status window will result in an error. This commit improves the tab-completion results for the focus command so that the status window is not included.
2023-01-25gdb/tui: convert if/error to an assertAndrew Burgess1-2/+5
While working on the previous commit, I realised that there was an error in tui_set_focus_command that could never be triggered. Since the big tui rewrite (adding dynamic layouts) it is no longer true that there is a tui_win_info object for every window at all times. We now only create a tui_win_info object for a particular window, when the window is part of the current layout. As a result, if we have a tui_win_info pointer, then the window must be visible inside tui_set_focus_command (this function calls tui_enable as its first action, which makes the current layout visible). The gdb.tui/tui-focus.exp test script exercises this area of code, and doesn't trigger the assert, nor do any of our other existing tui tests.
2023-01-25gdb/testsuite/tui: more testing of the 'focus' commandAndrew Burgess3-0/+93
I noticed that we didn't have many tests of the tui 'focus' command, so I started adding some. This exposed a bug in GDB; we are able to focus windows that should not be focusable, e.g. the 'status' window. This is harmless until we then do 'focus next' or 'focus prev', along this code path we assert that the currently focused window is focusable, which obviously, is not always true, so GDB fails with an assertion error. The fix is simple; add a check to the tui_set_focus_command function to ensure that the selected window is focusable. If it is not then an error is thrown. The new tests I've added cover this case.
2023-01-25gdb/testsuite: update gdb.tui/tui-nl-filtered-output.expAndrew Burgess1-21/+16
Following on from the previous commit, in this commit I am updating the test script gdb.tui/tui-nl-filtered-output.exp to take account of the changes in commit: commit 9162a27c5f5828240b53379d735679e2a69a9f41 Date: Tue Nov 13 11:59:03 2018 -0700 Change gdb test suite's TERM setting In the above commit the TERM environment variable was changed to be 'dumb' by default, which means that tests, that previously activated tui mode, no longer do unless TERM is set to 'ansi'. As the gdb.tui/tui-nl-filtered-output.exp script didn't do this, the test stopped working. As the expect patterns in this script were pretty generic no tests actually started failing, and we never noticed. In this commit I update the test script to correctly activate our terminal emulator, the test continues to pass after this update, but now we are testing in tui mode.
2023-01-25gdb/testsuite: update gdb.tui/tui-disasm-long-lines.expAndrew Burgess1-7/+14
Following on from the previous commit, in this commit I am updating the test script gdb.tui/tui-disasm-long-lines.exp to take account of the changes in commit: commit 9162a27c5f5828240b53379d735679e2a69a9f41 Date: Tue Nov 13 11:59:03 2018 -0700 Change gdb test suite's TERM setting In the above commit the TERM environment variable was changed to be 'dumb' by default, which means that tests, that previously activated tui mode, no longer do unless TERM is set to 'ansi'. As the gdb.tui/tui-disasm-long-lines.exp script didn't do this, the test stopped working. As the expect patterns in this script were pretty generic no tests actually started failing, and we never noticed. In this commit I update the script to use Term::clean_restart, which correctly sets TERM to 'ansi'. I've also added a check that the asm box does appear on the screen, which should indicate that tui mode has correctly activated. However, I also notice that GDB doesn't appear to fully work correctly. The test should display the disassembly for the test program, but it doesn't. The test is trying to disassemble some code that (deliberately) uses a very long symbol name, this eventually results in GDB entering tui_source_window_base::show_source_content and trying to allocate an ncurses pad in order to hold the current page of disassembler output. Unfortunately, due to the very long line, the call to newpad fails, meaning that tui_source_window_base::m_pad is nullptr. Luckily non of the following calls appear to crash when passed a nullptr, however, all the output that is written to the pad is lost, which is why we don't see any assembly code written to the screen. As the test history indicates that the script was originally checking for a crash in GDB when the long identifier was encountered, I think there is value in just leaving the test as it is for now, I have a fix for the issue of the newpad call failing, which I'll post in a follow up commit later.
2023-01-25gdb/testsuite: extend gdb.tui/tui-layout.exp test scriptAndrew Burgess1-11/+46
In passing I noticed that the gdb.tui/tui-layout.exp test script was a little strange, it tests the layout command multiple times, but never sets up our ANSI terminal emulator, so every layout command fails with a message about the terminal lacking the required abilities. It turns out that this was caused by this commit: commit 9162a27c5f5828240b53379d735679e2a69a9f41 Date: Tue Nov 13 11:59:03 2018 -0700 Change gdb test suite's TERM setting This was when we changed the testsuite to set the TERM environment variable to "dumb" by default. After this, any tui test that didn't set the terminal mode back to 'ansi' would fail to activate tui mode. For the tui-layout.exp test it just so happens that the test patterns are generic enough that the test continued to pass, even after this change. In this commit I have updated the test so we now check the layout command both with a 'dumb' terminal and with the 'ansi' terminal. When testing with the 'ansi' terminal, I have some limited validation that GDB correctly entered tui mode. I figured that it is probably worth having at least one test in the test suite that deliberately tries to enter tui mode in a dumb terminal, it would be sad if we one day managed to break GDB such that this caused a crash, and never noticed.
2023-01-25gdb/testsuite: rename test source file to match test scriptAndrew Burgess2-1/+1
The previous commit touched the source file for the test script gdb.cp/cpcompletion.exp. This source file is called pr9594.cc. The source file is only used by the one test script. This commit renames the source file to cpcompletion.cc to match the test script, this is more inline with how we name source files these days.
2023-01-25gdb/testsuite: use test_gdb_complete_unique more in C++ testsAndrew Burgess1-4/+4
Spotted in gdb.cp/cpcompletion.exp that we could replace some uses of gdb_test with test_gdb_complete_unique, this will extend the completion testing to check tab-completion as well as completion using the 'complete' command in some additional cases.
generated by cgit v1.1 at 2025-01-01 08:37:36 +0000