aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/lib
AgeCommit message (Collapse)AuthorFilesLines
2025-06-17[gdb/testsuite] Set interactive-mode to onTom de Vries1-0/+3
With MSYS2 and test-case gdb.ada/assign_1.exp, we get: ... (gdb) dir^M Reinitialize source path to empty? (y or n) \ [answered Y; input not from terminal]^M^M Source directories searched: $cdir;$cwd^M^M (gdb) ... GDB automatically answers the query, because interactive-mode is off: ... (gdb) show interactive-mode^M Debugger's interactive mode is auto (currently off).^M^M ... The correct value is on, because GDB was started in a terminal. For some reason, the auto value of interactive-mode is off instead. According to this patch [1], gdb doesn't recognize the pipes used by DejaGnu testsuite as an interactive setup. Fix this by adding "set interactive-mode on" to INTERNAL_GDBFLAGS, such that we get: ... (gdb) dir^M Reinitialize source path to empty? (y or n) y^M Source directories searched: $cdir;$cwd^M^M (gdb) ... and no longer need fixes like commit be740e7cc62 ("testsuite: skip confirmation in 'gdb_reinitialize_dir'") The fix is essentially the same as in aforementioned patch. For consistency, we apply the fix for all platforms. Co-Authored-By: Pierre Muller <muller@sourceware.org> Approved-By: Tom Tromey <tom@tromey.com> [1] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
2025-06-17[gdb/testsuite] Set TERM to dumb by defaultTom de Vries1-0/+27
With MSYS2 and default TERM=xterm-256color (as well as with xterm and ansi), I get: ... builtin_spawn gdb -q ... ^[[6n(gdb) ERROR: GDB never initialized. ... This is not specific to gdb, other tools produce the same CSI sequence, and consequently we run into trouble in other places (like get_compiler_info). Fix this by default-setting TERM to dumb. We do this for all platforms, to avoid test-cases passing on one platform but failing on another. For test-cases that set TERM to something other than dumb, handle the CSI sequence in default_gdb_start. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/33072 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33072
2025-06-11gdb testsuite: Introduce allow_multi_inferior_tests and use it throughoutPedro Alves1-0/+18
The Windows port does not support multi-process debugging. Testcases that want to exercise multi-process currently FAIL and some hit cascading timeouts. Add a new allow_multi_inferior_tests procedure, meant to be used with require, and sprinkle it throughout testcases as needed. Approved-by: Kevin Buettner <kevinb@redhat.com> Change-Id: I4a10d8f04f9fa10f4b751f140ad0a6d31fbd9dfb
2025-06-11gdb testsuite: Introduce allow_fork_tests and use it throughoutPedro Alves1-0/+16
Cygwin debugging does not support follow fork. There is currently no interface between the debugger and the Cygwin runtime to be able to intercept forks and execs. Consequently, testcases that try to exercise fork/exec all FAIL, and several hit long cascading timeouts. Add a new allow_fork_tests procedure, meant to be used with require, and sprinkle it throughout testcases that exercise fork. Note that some tests currently are skipped on targets other than Linux, with something like: # Until "set follow-fork-mode" and "catch vfork" are implemented on # other targets... # if {![istarget "*-linux*"]} { continue } However, some BSD ports also support fork debugging nowadays, and the testcases were never adjusted... That is why the new allow_fork_tests procedure doesn't look for linux. With this patch, on Cygwin, I get this: $ make check TESTS="*/*fork*.exp" ... === gdb Summary === # of expected passes 6 # of untested testcases 1 # of unsupported tests 31 Reviewed-By: Keith Seitz <keiths@redhat.com> Change-Id: I0c5e8c574d1f61b28d370c22a0b0b6bc3efaf978
2025-06-11gdb.multi/attach-no-multi-process.exp: Detect no remote non-stopPedro Alves1-1/+1
Running gdb.multi/attach-no-multi-process.exp on Cygwin, where GDBserver does not support non-stop mode, I see: FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: info threads FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout) FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout) Let's ignore the first "info threads" fail. The timeouts look like this: builtin_spawn /home/alves/gdb-cache-cygwin/gdb/../gdbserver/gdbserver --once --multi localhost:2346 Listening on port 2346 target extended-remote localhost:2346 Remote debugging using localhost:2346 Non-stop mode requested, but remote does not support non-stop (gdb) gdb_do_cache: can_spawn_for_attach ( ) builtin_spawn /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.multi/attach-no-multi-process/attach-no-multi-process attach 14540 FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout) info threads FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout) Note the "Non-stop mode requested, but remote does not support non-stop" line. The intro to gdb_target_cmd_ext says: # gdb_target_cmd_ext # Send gdb the "target" command. Returns 0 on success, 1 on failure, 2 on # unsupported. That's perfect here, we can just use gdb_target_cmd_ext instead of gdb_target_cmd, and check for 2 (unsupported). That's what this patch does. However gdb_target_cmd_ext incorrectly returns 1 instead of 2 for the case where the remote target says it does not support non-stop. That is also fixed by this patch. With this, we no longer get those timeout fails. We get instead: target extended-remote localhost:2346 Remote debugging using localhost:2346 Non-stop mode requested, but remote does not support non-stop (gdb) UNSUPPORTED: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: non-stop RSP Approved-by: Kevin Buettner <kevinb@redhat.com> Change-Id: I1ab3162f74200c6c02a17a0600b102d2d12db236
2025-06-09Support core dumping testcases with Cygwin's dumperPedro Alves1-1/+6
Cygwin supports dumping ELF cores via a dumper.exe utility, see https://www.cygwin.com/cygwin-ug-net/dumper.html. When I run a testcase that has the "kernel" generate a corefile, like gdb.base/corefile.exp, Cygwin invokes dumper.exe correctly and generates an ELF core file, however, the testsuite doesn't find the generated core: Running /home/alves/gdb/src/gdb/testsuite/gdb.base/corefile.exp ... WARNING: can't generate a core file - core tests suppressed - check ulimit -c The file is correctly put under $coredir, e.g., like so: outputs/gdb.base/corefile/coredir.8926/corefile.exe.core The problem is in this line in core_find: foreach i "${coredir}/core ${coredir}/core.coremaker.c ${binfile}.core" { Note that that isn't looking for "${binfile}.core" inside ${coredir}... That is fixed in this patch. However, that still isn't sufficient for Cygwin + dumper, as in that case the core is going to be called foo.exe.core, not foo.core. Fix that by looking for foo.exe.core in the core dir as well. With this, gdb.base/corefile.exp and other tests that use core_find now run. They don't pass cleanly, but at least now they're exercised. Approved-By: Tom Tromey <tom@tromey.com> Change-Id: Ic807dd2d7f22c5df291360a18c1d4fbbbb9b993e
2025-06-06Make default_gdb_exit resilient to failed closesPedro Alves1-1/+3
For some reason, when testing GDB on Cygwin, I get: child process exited abnormally while executing "exec sh -c "exec > /dev/null 2>&1 && (kill -2 -$spid || kill -2 $spid)"" (procedure "close_wait_program" line 20) invoked from within "close_wait_program $shell_id $pid" (procedure "standard_close" line 23) invoked from within "standard_close "Windows-ROCm"" ("eval" body line 1) invoked from within "eval ${try}_${proc} \"$dest\" $args" (procedure "call_remote" line 42) invoked from within "call_remote "" close $host" (procedure "remote_close" line 3) invoked from within "remote_close host" (procedure "log_and_exit" line 30) invoked from within "log_and_exit" When that happens from within clean_restart, clean_restart doesn't clear the gdb_spawn_id variable, and then when clean_restart starts up a new GDB, that sees that gdb_spawn_id is already set, so it doesn't actually spawn a new GDB, and so clean_restart happens to reuse the same GDB (!). Many tests happen to actually work OK with this, but some don't, and the failure modes can be head-scratching. Of course, the failure to close GDB should be fixed, but when it happens, I think it's good to not end up with the current weird state. Connecting the "child process exit abnormally" errors at the end of a testcase run with weird FAILs in other testcases took me a while (as in, weeks!), it wasn't obvious to me immediately. Thus, this patch makes default_gdb_exit more resilient to failed closes, so that gdb_spawn_id is unset even is closing GDB fails, and we move on to start a new GDB. Approved-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I9ec95aa61872a40095775534743525e0ad2097d2
2025-06-06gdb_test_multiple: Anchor prompt match if -lblPedro Alves1-1/+3
The testcase added by this patch has a gdb_test_multiple call that wants to match different lines of output that all have a common prefix, and do different actions on each. Instead of a single regular expression with alternatives, it's clearer code if the different expressions are handled with different "-re", like so: gdb_test_multiple "command" "" -lbl { -re "^command(?=\r\n)" { exp_continue } -re "^\r\nprefix foo(?=\r\n)" { # Some action for "foo". exp_continue } -re "^\r\nprefix bar(?=\r\n)" { # Some action for "bar". exp_continue } -re "^\r\nprefix \[^\r\n\]*(?=\r\n)" { # Some action for all others. exp_continue } -re "^\r\n$::gdb_prompt $" { gdb_assert {$all_prefixes_were_seen} $gdb_test_name } } Above, the leading anchors in the "^\r\nprefix..." matches are needed to avoid too-eager matching due to the common prefix. Without the anchors, if the expect output buffer happens to contain at least: "\r\nprefix xxx\r\nprefix foo\r\n" ... then the "prefix foo" pattern match inadvertently consumes the first "prefix xxx" line. Without the anchor in the prompt match, like: -re "\r\n$::gdb_prompt $" { gdb_assert {$all_prefixes_were_seen} $gdb_test_name } Or the equivalent: -re -wrap "" { gdb_assert {$all_prefixes_were_seen} $gdb_test_name } ... then if the expect buffer contains: "\r\nmeant-to-be-matched-by-lbl\r\nprefix foo\r\n$gdb_prompt " ... then the prompt regexp matches this, consuming the "prefix" line inadvertently, and we get a FAIL. The built-in regexp matcher for -lbl doesn't get a chance to match the "\r\nmeant-to-be-matched-by-lbl\r\n" part, because the built-in prompt match appears first within gdb_test_multiple. By adding the anchor to the prompt regexp, we avoid that problem. However, the same expect output buffer contents will still match the built-in prompt regexp. That is what is fixed by this patch. It makes it so that if -lbl is specified, the built-in prompt regexp has a leading anchor. Original idea for turning this into a gdb.testsuite/ testcase by Tom de Vries <tdevries@suse.de>. Approved-By: Tom de Vries <tdevries@suse.de> Change-Id: Ic2571ec793d856a89ee0d533ec363e2ac6036ea2
2025-05-26gdb/testsuite: Clarify -lbl option in gdb_test_multipleThiago Jung Bauermann1-1/+4
I was a bit confused about the -lbl option in gdb_test_multiple, and needed to read its implementation to determine that it would be useful for my needs. Explicitly mention what the option does and why it's useful to hopefully help other developers. Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-05-23[gdb/testsuite] Add gdb.dwarf2/fission-dw-form-strx.expTom de Vries1-5/+26
Add a dwarf assembly test-case using a DW_FORM_strx in a .dwo file. Tested on x86_64-linux. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-05-14testsuite: fix gdb_exit for MinGW targetRohr, Stephan1-1/+2
GDB is not properly exited via 'remote_close host' when running the testsuite in a MinGW environment. Use the 'quit' command to properly exit the GDB debugging session. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-14testsuite: get windows PID on MinGW targetRohr, Stephan1-1/+1
Also translate the MinGW PID to the Windows PID when running on a MinGW target. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-06gdb/testsuite: add gcore_cmd_available predicate procAndrew Burgess1-0/+18
Add a new gcore_cmd_available predicate proc that can be used in a 'requires' line, and make use of it in a few tests. All of the tests I have modified call gdb_gcore_cmd as one of their first actions and exit if the gcore command is not available, so it makes sense (I think) to move the gcore command check into a requires call. There should be no change in what is actually run after this commit.
2025-05-02[gdb/testsuite] Add gdb.dwarf2/dw-form-strx.expTom de Vries1-0/+42
Add a test-case using DW_FORM_strx. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-04-23This commit adds record full support for rv64gc instruction setTimur1-1/+2
It includes changes to the following files: - gdb/riscv-linux-tdep.c, gdb/riscv-linux-tdep.h: adds facilities to record syscalls. - gdb/riscv-tdep.c, gdb/riscv-tdep.h: adds facilities to record execution of rv64gc instructions. - gdb/configure.tgt: adds new files for compilation. - gdb/testsuite/lib/gdb.exp: enables testing of full record mode for RISC-V targets. - gdb/syscalls/riscv-canonicalize-syscall-gen.py: a script to generate function that canonicalizes RISC-V syscall. This script can simplify support for syscalls on rv32 and rv64 system (currently support only for rv64). To use this script you need to pass a path to a file with syscalls description from riscv-glibc (example is in the help message). The script produces a mapping from syscall names to gdb_syscall enum. - gdb/riscv-canonicalize-syscall.c: the file generated by the previous script. - gdb/doc/gdb.texinfo: notification that record mode is enabled in RISC-V. - gdb/NEWS: notification of new functionality. Approved-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-04-22Handle DWARF 5 separate debug sectionsTom Tromey1-0/+18
DWARF 5 standardized the .gnu_debugaltlink section that dwz emits in multi-file mode. This is handled via some new forms, and a new .debug_sup section. This patch adds support for this to gdb. It is largely straightforward, I think, though one oddity is that I chose not to have this code search the system build-id directories for the supplementary file. My feeling was that, while it makes sense for a distro to unify the build-id concept with the hash stored in the .debug_sup section, there's no intrinsic need to do so. This in turn means that a few tests -- for example those that test the index cache -- will not work in this mode. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32808 Acked-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-22gdb/python: restructure the existing memory leak testsAndrew Burgess1-0/+21
We currently have two memory leak tests in gdb.python/ and there's a lot of duplication between these two. In the next commit I'd like to add yet another memory leak test, which would mean a third set of scripts which duplicate the existing two. And three is where I draw the line. This commit factors out the core of the memory leak tests into a new module gdb_leak_detector.py, which can then be imported by each tests's Python file in order to make writing the memory leak tests easier. I've also added a helper function to lib/gdb-python.exp which captures some of the common steps needed in the TCL file in order to run a memory leak test. Finally, I use this new infrastructure to rewrite the two existing memory leak tests. What I considered, but ultimately didn't do, is merge the two memory leak tests into a single TCL script. I did consider this, and for the existing tests this would be possible, but future tests might require different enough setup that this might not be possible for all future tests, and now that we have helper functions in a central location, the each individual test is actually pretty small now, so leaving them separate seemed OK. There should be no change in what is actually being tested after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-04-09[gdb/symtab] Handle DW_OP_entry_value at function entryTom de Vries1-2/+21
On riscv64-linux, with test-case gdb.base/vla-optimized-out.exp I ran into: ... (gdb) p sizeof (a)^M $2 = <optimized out>^M (gdb) FAIL: $exp: o1: printed size of optimized out vla ... The variable a has type 0xbf: ... <1><bf>: Abbrev Number: 12 (DW_TAG_array_type) <c0> DW_AT_type : <0xe3> <c4> DW_AT_sibling : <0xdc> <2><c8>: Abbrev Number: 13 (DW_TAG_subrange_type) <c9> DW_AT_type : <0xdc> <cd> DW_AT_upper_bound : 13 byte block: a3 1 5a 23 1 8 20 24 8 20 26 31 1c (DW_OP_entry_value: (DW_OP_reg10 (a0)); DW_OP_plus_uconst: 1; DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; DW_OP_minus) ... which has an upper bound using a DW_OP_entry_value, and since the corresponding call site contains no information to resolve the value of a0 at function entry: ... <2><6b>: Abbrev Number: 6 (DW_TAG_call_site) <6c> DW_AT_call_return_pc: 0x638 <74> DW_AT_call_origin : <0x85> ... evaluting the dwarf expression fails, and we get <optimized out>. My first thought was to try breaking at *f1 instead of f1 to see if that would help, but actually the breakpoint resolved to the same address. In other words, the inferior is stopped at function entry. Fix this by resolving DW_OP_entry_value when stopped at function entry by simply evaluating the expression. This handles these two cases (x86_64, using reg rdi): - DW_OP_entry_value: (DW_OP_regx: 5 (rdi)) - DW_OP_entry_value: (DW_OP_bregx: 5 (rdi) 0; DW_OP_deref_size: 4) Tested on x86_64-linux. Tested gdb.base/vla-optimized-out.exp on riscv64-linux. Tested an earlier version of gdb.dwarf2/dw2-entry-value-2.exp on riscv64-linux, but atm I'm running into trouble on that machine (cfarm92) so I haven't tested the current version there.
2025-04-08gdb/testsuite/dwarf: fix abbrev section name when putting type unit in DWO fileSimon Marchi1-1/+1
Fix what looks like a copy paste error resulting in the wrong abbrev section name. The resulting section name in my test was ".debug_info.dwo.dwo", when it should have been ".debug_abbrev.dwo". Change-Id: I82166d8ac6eaf3c3abc15d2d2949d00c31fe79f4 Approved-By: Tom Tromey <tom@tromey.com>
2025-04-08gdb/testsuite/dwarf: add support to generate DWARF 5 split compile unitsSimon Marchi1-1/+44
Add support to the DWARF assembler to generate DWARF 5 split compile units. The assembler knows how to generate DWARF < 5 split compile units (fission), DWARF 5 compile units, but not DWARF 5 split compile units. What's missing is: - using the right unit type in the header: skeleton for the unit in the main file and split_compile for the unit in the DWO file - have a way for the caller to specify the DWO ID that will end up in the unit header Add a dwo_id parameter to the cu proc. In addition to specifying the DWO ID, the presence of this parameter tells the assembler to use the skeleton or split_compile unit type. This is used in a subsequent patch. Change-Id: I05d9b189a0843ea6c2771b1d5e5a91762426dea9 Approved-By: Tom Tromey <tom@tromey.com>
2025-04-08Update copyright dates to include 2025Tom Tromey60-60/+60
This updates the copyright headers to include 2025. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script. Approved-By: Eli Zaretskii <eliz@gnu.org>
2025-04-03[gdb/testsuite] Add gdb.testsuite/version-compare.expTom de Vries1-1/+4
Add a test-case gdb.testsuite/version-compare.exp that excercises proc version_compare, and a note to proc version_compare that it considers v1 < v1.0 instead of v1 == v1.0. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-04-01Check gnatmake version in gnat_version_compareTom Tromey1-3/+7
Tom de Vries pointed out that my earlier change to gnat_version_compare made it actually test gcc's version -- not gnat's. This patch changes gnat_version_compare to examine gnatmake's version, while preserving the nicer API. Approved-By: Tom de Vries <tdevries@suse.de>
2025-03-31testsuite: fix is_aarch32_targetThiago Jung Bauermann1-6/+9
Commit c221b2f77080 Testsuite: Add gdb_can_simple_compile changed the source file name extension of the test program from .s to .c resulting in compile fails. This, in turn, causes is_aarch32_target checks to fail. Change the test source from an assembly program to a C program using inline assembly. is_amd64_regs_target had a similar problem, which was fixed by commit 224d30d39365 testsuite: fix is_amd64_regs_target This fix — and commit message — are mostly copied from it. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-26gdb/testsuite: Force DWARF debuginfo where applicable in AIX systemsGuinevere Larsen1-0/+17
In the AIX systems available for testing in the gcc compile farm, the default debug information format is stabs. This is a problem for many reasons, mainly that stabs is not as complete as dwarf and stabs is being deprecated in the next release. In the current state, we have: PASS: 39798 FAIL: 7405 When running these tests, I unfortunately didn't have the foresight to save the number of unsupported and untested cases. To improve testing there, this patch changes the gdb_compile TCL proc, so that if we're running tests in AIX, we requested debug info, and we haven't explicitly asked for some debuginfo format, gdb_compile will add -gdwarf to the compilation line, forcing DWARF to be used. After this patch, we get: PASS: 74548 FAIL: 5963 So not only do we have fewer failures, there are tens of thousands of tests that are no longer skipped. Approved-By: Tom Tromey <tom@tromey.com>
2025-03-26gdb: add configure option to disable compileGuinevere Larsen2-0/+9
GDB's compile subsystem is deeply tied to GDB's ability to understand DWARF. A future patch will add the option to disable DWARF at configure time, but for that to work, the compile subsystem will need to be entirely disabled as well, so this patch adds that possibility. I also think there is motive for a security conscious user to disable compile for it's own sake. Considering that the code is quite unmaintained, and depends on an equally unmaintained gcc plugin, there is a case to be made that this is an unnecessary increase in the attack surface if a user knows they won't use the subsystem. Additionally, this can make compilation slightly faster and the final binary is around 3Mb smaller. But these are all secondary to the main goal of being able to disable dwarf at configure time. To be able to achieve optional compilation, some of the code that interfaces with compile had to be changed. All parts that directly called compile things have been wrapped by ifdefs checking for compile support. The file compile/compile.c has been setup in a similar way to how python's and guile's main file has been setup, still being compiled but only for with placeholder command. Finally, to avoid several new errors, a new TCL proc was introduced to gdb.exp, allow_compile_tests, which checks if the "compile" command is recognized before the inferior is started and otherwise skips the compile tests. All tests in the gdb.compile subfolder have been updated to use that, and the test gdb.base/filename-completion also uses this. The proc skip_compile_feature_tests to recognize when the subsystem has been disabled at compile time. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-03-21gdb/testsuite/lib/rocm: Drop hip_devices_support_precise_memoryLancelot SIX1-19/+0
Remove hip_devices_support_precise_memory as this is not used anymore. Change-Id: If5e19cf81f8b8778ee11b27d99b8488562804967 Approved-by: Pedro Alves <pedro@palves.net>
2025-03-18[gdb/testsuite] Fix gdb.base/enum_cond.exp on arm-linuxTom de Vries1-0/+12
On arm-linux, I run into: ... gdb compile failed, ld: warning: enum_cond.o uses variable-size enums yet \ the output is to use 32-bit enums; use of enum values across objects may fail UNTESTED: gdb.base/enum_cond.exp: failed to compile ... Fix this by using -nostdlib. Tested on arm-linux and x86_64-linux. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-04Check whether gnatmake can link with -sharedTom Tromey1-0/+9
Currently, gnat-llvm does not ship a shared libgnat. This patch changes the relevant test to check whether linking with -shared actually works.
2025-03-04Check whether gnatmake supports -OgTom Tromey1-0/+5
gnat-llvm does not support the -Og flag. This arranges to check for this flag before using it.
2025-03-04Look for -fgnat-encodings optionTom Tromey1-1/+17
gnat-llvm does not support the -fgnat-encodings option, and does not emit GNAT encodings at all -- it only supports the equivalent of GCC's "minimal" encodings; which is to say, ordinary DWARF. This patch changes gdb to test whether gnatmake supports this flag and adapt accordingly. foreach_gnat_encoding is changed to pretend that the "minimal" mode is in effect, as some test examine the mode.
2025-03-04Check -fvar-tracking via ada_simple_compileTom Tromey1-0/+5
A couple of Ada tests check whether the C compiler supports -fvar-tracking. However, this doesn't really work when using gnat-llvm, because that will invoke clang under the hood. This patch arranges to check gnatmake instead, which is more robust even when toolchains are mix-and-matched.
2025-03-04Introduce ada_simple_compileTom Tromey2-11/+56
This introduces ada_simple_compile, an Ada-specific analog of gdb_simple_compile. gdb_compile_test is split into two procs to make this possible. ada_simple_compile isn't used in this patch but will be by later patches in this series.
2025-03-03Add language to type unit in debug-names-tu.exp.tclTom Tromey1-24/+32
I think debug-names-tu.exp.tcl only passes by accident -- the type unit does not have a language, which gdb essentially requires. This isn't noticeable right now because the type unit in question is expanded in one phase and then the symbol found in another. However, I'm working on a series that would regress this. This patch partially fixes the problem by correcting the test case, adding the language to the TU. Hoewver, it then goes a bit further and arranges for this information not to be written to .debug_names. Whether or not a type should be considered "static" seems like something that is purely internal to gdb, so this patch has the entry-creation function apply the appropriate transform. It also may make sense to change the "debug_names" proc in the test suite to process attributes more like the ordinary "cu" proc does.
2025-02-24gdb/tui: use correct setting to control asm window stylingAndrew Burgess1-4/+19
Currently the TUI's asm window uses `source_styling` to control styling. This setting is supposed to be for styling of source files though, and the asm window displays disassembler output. We have a different setting for this `disassemble_styling`, which is controlled with 'set style disassembler enabled on|off'. Switch to use the correct control variable. I've written a new test for this, but this required some additions to the tuiterm library in order to grab character attributes for a screen region. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-24gdb/testsuite/lib/rocm.exp: Fix a typo in a commentShahab Vahedi1-1/+1
"Check we have ..." --> "Check if we have ..." This is for consistency with the previous comment and the code downstream.
2025-02-21gdb/testsuite/rocm.exp: Use system GPU(s) to detect featuresShahab Vahedi1-36/+74
gdb/testsuite/rocm.exp: Use system GPU(s) to detect features Background ---------- This patch revisits the purpose of hcc_amdgpu_targets{} in order to address the separation of concerns between: - GPU targets passed to the compiler. This kind of target is passed as an argument to flags like "--offload-arch=...", "--targets=...", etc. - GPU targets as in available GPU devices on the system. This is crucial for finding which capabilities are available, and therefore which tests should be executed or skipped. Code change ----------- - A new "find_amdgpu_devices{}" procedure is added. It is responsible for listing the GPU devices that are available on the system. - "hcc_amdgpu_targets{}" is rewritten to use the newly added "find_amdgpu_devices{}" when there's no environment variable (HCC_AMDGPU_TARGET) set. - The output of "hcc_amdgpu_targets{}" is now only used in places that set the target for the building toolchains. - The output of "find_amdgpu_devices{}" is used anywhere that needs to evaluate the GPU features. Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu) Change-Id: Ib11021dbe674aa40192737ede78284a1bc531513
2025-02-18testsuite, mi: prevent buffer overflow in get_mi_thread_listTankut Baris Aktemur1-25/+26
If there is a large number of threads in the input program, the expect buffer in `get_mi_thread_list` would become full. Prevent this by consuming the buffer in small pieces. Regression-tested using the gdb.mi tests. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-02-18[gdb] Fix some typosTom de Vries3-5/+5
Fix typos: ... overriden -> overridden reate -> create ... Tested on x86_64-linux. I
2025-02-17testsuite, mi: fix indentation in get_mi_thread_listTankut Baris Aktemur1-29/+29
The `get_mi_thread_list` procedure's body is incorrectly indented. Fix it. There is one line that was already long. Consider it an exception and don't bother breaking it.
2025-02-13gdb, testsuite: Rename set_sanitizer procedures to append_environment.Christina Schimpe1-9/+9
The procedures set_sanitizer_1, set_sanitizer and set_sanitizer_default are used for the configuration of ASAN specific environment variables. However, they are actually generic. Rename them to append_environment* so that their purpose is more clear. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-12Add copyright header to gnat_debug_info_test.adbTom Tromey1-0/+15
I noticed that gdb/testsuite/lib/gnat_debug_info_test.adb is missing a copyright header. This adds one, using the date range from the original commit.
2025-02-09gdb: include a still-mapped flag in solib unload notificationAndrew Burgess2-33/+33
Consider the gdb.base/dlmopen.exp test case. The executable in this test uses dlmopen to load libraries into multiple linker namespaces. When a library is loaded into a separate namespace, its dependencies are also loaded into that namespace. This means that an inferior can have multiple copies of some libraries, including the dynamic linker, loaded at once. However, glibc optimises at least the dynamic linker case. Though the library appears to be mapped multiple times (it is in the inferior's solib list multiple times), there is really only one copy mapped into the inferior's address space. Here is the 'info sharedlibrary' output on an x86-64/Linux machine once all the libraries are loaded: (gdb) info sharedlibrary From To Syms Read Shared Object Library 0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7eda3d0 0x00007ffff7f4e898 Yes /lib64/libm.so.6 0x00007ffff7d0e800 0x00007ffff7e6dccd Yes /lib64/libc.so.6 0x00007ffff7fbd040 0x00007ffff7fbd116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so 0x00007ffff7fb8040 0x00007ffff7fb80f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so 0x00007ffff7bfe3d0 0x00007ffff7c72898 Yes /lib64/libm.so.6 0x00007ffff7a32800 0x00007ffff7b91ccd Yes /lib64/libc.so.6 0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7fb3040 0x00007ffff7fb3116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so 0x00007ffff7fae040 0x00007ffff7fae0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so 0x00007ffff7ce1040 0x00007ffff7ce1116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so 0x00007ffff7cdc040 0x00007ffff7cdc0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so 0x00007ffff79253d0 0x00007ffff7999898 Yes /lib64/libm.so.6 0x00007ffff7759800 0x00007ffff78b8ccd Yes /lib64/libc.so.6 0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7cd7040 0x00007ffff7cd7116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.2.so Notice that every copy of /lib64/ld-linux-x86-64.so.2 is mapped at the same address. As the inferior closes the libraries that it loaded, the various copies of the dynamic linker will also be unloaded. Currently, when this happens GDB calls notify_solib_unloaded, which triggers the gdb::observers::solib_unloaded observer. This observer will call disable_breakpoints_in_unloaded_shlib (in breakpoint.c), which disables any breakpoints in the unloaded solib. The problem with this, is that, when the dynamic linker (or any solib) is only really mapped once as is the case here, we only want to disable breakpoints in the library when the last instance of the library is unloaded. The first idea that comes to mind is that GDB should not emit the solib_unloaded notification if a shared library is still in use, however, this could break MI consumers. Currently, every time a copy of ld-linux-x86-64.so.2 is unloaded, GDB's MI interpreter will emit a =library-unloaded event. An MI consumer might use this to update the library list that it displays to the user, and fewer notify_solib_unloaded calls will mean fewer MI events, which will mean the MI consumer's library list could get out of sync with GDB. Instead I propose that we extend GDB's solib_unloaded event to add a new flag. The new flag indicates if the library mapping is still in use within the inferior. Now the MI will continue to emit the expected =library-unloaded events, but disable_breakpoints_in_unloaded_shlib can check the new flag, when it is true (indicating that the library is still mapped into the inferior), no breakpoints should be disabled. The other user of the solib_unloaded observer, in bsd-uthread.c, should, I think, do nothing if the mapping is still in use. This observer is also disabling breakpoints when a library is unloaded. Most of the changes in this commit relate to passing the new flag around for the event. The interesting changes are mostly in solib.c, where the flag value is determined, and in breakpoint.c and bsd-uthread.c, where the flag value is read. There's a new MI test, the source of which is mostly copied from the gdb.base/dlmopen.exp test. This new test is checking we see all the expected =library-unloaded events.
2025-02-06gdb/testsuite: gdb.base/gcorebg.exp against installed binariesLancelot SIX1-17/+17
It is possible to run GDB's testsuite against installed binaries rather than the one from the build tree. For example, one could do: $ make check-gdb RUNTESTFLAGS=GDB=/usr/bin/gdb Running the testsuite this way causes error for gdb.base/gcorebg.exp: Running [...]/gdb/testsuite/gdb.base/gcorebg.exp ... FAIL: gdb.base/gcorebg.exp: detached=detached: Spawned gcore finished FAIL: gdb.base/gcorebg.exp: detached=detached: Core file generated by gcore FAIL: gdb.base/gcorebg.exp: detached=standard: Spawned gcore finished FAIL: gdb.base/gcorebg.exp: detached=standard: Core file generated by gcore This is due to 2 problems. First, when running this way, the $GDB_DATA_DIRECTORY is not set (on purpose) as the installed GDB does not need to be specified where to find it. See this section in gdb/testsuite/lib/gdb.exp: if ![info exists GDB] { [....] } else { # If the user specifies GDB on the command line, and doesn't # specify GDB_DATA_DIRECTORY, then assume we're testing an # installed GDB, and let it use its own configured data directory. if ![info exists GDB_DATA_DIRECTORY] { set GDB_DATA_DIRECTORY "" } } The testbg.exp file always assumes a non-empty GDB_DATA_DIRECTORY. As a consequence, when calling the gcorebg binary with an empty argument (i.e. missing argument), the program fails: gcorebg: [...]/gdb/testsuite/gdb.base/gcorebg.c:42: main: Assertion `argc == 5' failed. FAIL: gdb.base/gcorebg.exp: detached=standard: Spawned gcore finished This patch does adjust the gcorebg.c and gcorebg.exp files to allow not specifying the data-directory. The other issue is that the testsuite assumes that the `gcore` to test is always the one from the build tree. However, if someone is testing an installed binary by setting GDB, I think that person would expect to test the `gcore` script next to the binary that was specified (unless GCORE is specified to explicitly specified). This patch does that adjustment as well. To that end, it needs to move the block setting GCORE after the block setting GDB. Change-Id: I070e039903c0b5afeac357d8fac7d710ff6697b9 Approved-By: Tom Tromey <tom@tromey.com>
2025-01-30gdb: add first gdbreplay test, connect.expAlexandra Hájková1-0/+143
When the changes on the remote protocol are made, we want to test all the corner cases to prevent regressions. Currently it can be tricky to simulate some corner case conditions that would expose possible regressions. When I want to add or change the remote protocol packet, I need to hack gdbserver to send a corrupted packet or an error to make sure GDB is able to handle such a case. This test makes it easy to send a corruped packet or an error message to GDB using the gdbreplay tool and check GDB deals with it as we expect it to. This test starts a communication with gdbsever setting the remotelog file. Then, it modifies the remotelog with update_log proc, injects an error message instead of the expected replay to the vMustReplyEmpty packet in order to test GDB reacts to the error response properly. After the remotelog modification, this test restarts GDB and starts communication with gdbreply instead of the gdbserver using the remotelog. Add a lib/gdbreplay-support.exp. update_log proc matches lines from GDB to gdbserver in a remotelogfile. Once a match is found then the custom line is used to build a replacement line to send from gdbserver to GDB. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-29Use command style in "help" commandTom Tromey1-2/+2
This changes the help command to use the new command style when displaying text like: List of "catch" subcommands: As a side effect, this mildly -- but not hugely -- cleans up some i18n issues in help_list. The header comment for that function is also changed to the gdb style. Finally, this function used to print something like: Type "help catch" followed by catch subcommand name for full documentation. The second "catch" here seems redundant to me, so this patch removes it.
2025-01-29gdb/testsuite: add comments to line table from DWARF assemblerAndrew Burgess1-7/+7
Add comments to the assembler generated by the DWARF assembler that builds the line table. I found these comments useful when debugging issues with the line table parsing. This patch should make no difference to what is being tested. The test binaries should be unchanged after this commit. Approved-By: Kevin Buettner <kevinb@redhat.com>
2025-01-22Remove gnatmake_version_at_leastTom Tromey1-21/+0
This removes gnatmake_version_at_least in favor of using the more flexible gnat_version_compare. I think these two version numbers should be the same, as gnatmake is shipped with the compiler.
2025-01-16[gdb/testsuite] Fix timeouts in gdb.threads/step-over-thread-exit.expTom de Vries1-1/+8
Once in a while, I run into a timeout in test-case gdb.threads/step-over-thread-exit.exp: ... (gdb) continue^M Continuing.^M [New Thread 0xfffff7cff1a0 (LWP 2874854)]^M ^M Thread 97 "step-over-threa" hit Breakpoint 2, 0x0000000000410314 in \ my_exit_syscall () at gdb/testsuite/lib/my-syscalls.S:74^M 74 SYSCALL (my_exit, __NR_exit)^M (gdb) [Thread 0xfffff7cff1a0 (LWP 2874853) exited]^M FAIL: $exp: step_over_mode=displaced: non-stop=on: target-non-stop=on: \ schedlock=off: cmd=continue: ns_stop_all=0: iter 95: continue (timeout) ... I can reproduce it more frequently by running with taskset -c <slow core id>. Fix this by using -no-prompt-anchor. This requires us to add -no-prompt-anchor to proc gdb_test_multiple. Tested on aarch64-linux. PR testsuite/32489 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32489
2025-01-15gdb/testsuite: make gdb.reverse/i386-avx-reverse.exp require also avx2Jan Vrany1-0/+45
The test gdb.reverse/i386-avx-reverse.exp requires CPU to have AVX instructions but it actually also uses AVX2 instructions (like vpcmpeqd). This caused the test to fail on CPUs that have AVX but not AVX2. This commit adds check for AVX2. Tested on Intel Xeon CPU E3-1265L (no AVX2) and Intel Core i7-1355U (has AVX2).