aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/lib
AgeCommit message (Collapse)AuthorFilesLines
16 hours[gdb/testsuite] Remove more uses of "eval"Tom de Vries3-7/+7
Remove some more uses of the Tcl "eval" proc. In most cases the {*} "splat" expansion is used instead. The exceptions are: - gdb.base/inferior-args.exp where we rewrite: set cmd [format "lappend item \{ '%c' '\\%c' \}" 34 34] eval $cmd into: lappend item [format { '%c' '\%c' } 34 34] - reset_vars in lib/check-test-names.exp where we simply drop an unnecessary eval Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
21 hoursTreat attributes as code in DWARF assemblerTom Tromey1-65/+33
The DWARF assembler treats the 'children' of a DIE as plain Tcl code, evaluating it in the parent context. I don't recall why, but when I wrote this code, I didn't do the same thing for the attributes. Instead, there I implemented a special syntax. I was looking at this today and wondered why I didn't just use ordinary evaluation as well. This patch implements this idea. Attributes are now evaluated as plain code. This is a bit less "magical", is slightly shorter due to lack of braces, and most importantly now allows comments in the attributes section. Note that some [subst {}] calls had to be added. This could be fixed by changing DWARF expressions to also be plain Tcl code. I think that would be a good idea, but I didn't want to tack it on here. This patch requires the full ("DW_AT_...") name for attributes. I did this to avoid any possibility of name clashes. I've long considered that my original decision to allow short names for tags and attributes was a mistake. It's worth noting that many existing tests already used the long names here. Most of this patch was written by script. The main changes are in dwarf.exp, but as noted, there were some minor fixups needed in some tests. Also, after committing, 'git show' indicated some whitespace issues, so I've gone through and "tabified" some things, which is why the patch might be otherwise larger than it should be. (This was discussed a bit during the v1 submission.) v1 was here: https://inbox.sourceware.org/gdb-patches/20250530183845.2179955-1-tromey@adacore.com/ In v2 I've rebased and fixed up various tests that either changed or were added since v1. Regression tested on x86-64 Fedora 41. Approved-By: Simon Marchi <simon.marchi@efficios.com>
25 hoursFix nested gdb_caching_proc with argsPedro Alves1-19/+2
Commit d09eba07 ("Make get_compiler_info use gdb_caching_proc") regressed some tests when you run them in isolation (as this depends on the order the gdb_caching_proc procs' results are cached). E.g.: Running /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp ... ERROR: tcl error sourcing /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp. ERROR: tcl error code TCL WRONGARGS ERROR: wrong # args: should be "gdb_real__get_compiler_info_1 language" while executing "gdb_real__get_compiler_info_1" ("uplevel" body line 1) invoked from within "uplevel 2 $real_name" (procedure "gdb_do_cache_wrap" line 3) invoked from within "gdb_do_cache_wrap $real_name {*}$args" (procedure "gdb_do_cache" line 98) invoked from within gdb.base/attach.exp triggers it too, for example. This is actually a latent problem in gdb_do_cache_wrap, introduced in: commit 71f1ab80f1aabd70bce526635f84c7b849e8a0f4 CommitDate: Mon Mar 6 16:49:19 2023 +0100 [gdb/testsuite] Allow args in gdb_caching_proc This change: # Call proc real_name and return the result, while ignoring calls to pass. -proc gdb_do_cache_wrap {real_name} { +proc gdb_do_cache_wrap {real_name args} { if { [info procs save_pass] != "" } { return [uplevel 2 $real_name] <<<<<<<<<<<<<<<<<<<<<<< HERE } @@ -31,7 +31,7 @@ proc gdb_do_cache_wrap {real_name} { rename pass save_pass rename ignore_pass pass - set code [catch {uplevel 2 $real_name} result] + set code [catch {uplevel 2 [list $real_name {*}$args]} result] Missed updating the line marked with HERE above, to pass down $args. So the case of a caching proc calling another caching proc with args isn't handled correctly. We could fix this by fixing the HERE line like so: - return [uplevel 2 $real_name] + return [uplevel 2 [list $real_name {*}$args]] However, we have with_override nowadays that we can use here which eliminates the duplicated logic, which was what was missed originally. A new test that exposes the problem is added to gdb.testsuite/gdb-caching-proc.exp. This also adds a new test to gdb.testsuite/with-override.exp that I think was missing, making sure that the inner foo override restores the outer foo override. Tested-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I8b2a7366bf910902fe5f547bde58c3b475bf5133
42 hoursMake get_compiler_info use gdb_caching_procPedro Alves1-28/+24
While running tests on Windows with: $ make check-parallel RUNTESTFLAGS="-v" I noticed that get_compiler_info was invoking the compiler over and over for each testcase, even though the result is supposed to be cached. This isn't normally very visible in gdb.log, because we suppress it there: # Run $ifile through the right preprocessor. # Toggle gdb.log to keep the compiler output out of the log. set saved_log [log_file -info] log_file ... I'm not sure it's a good idea to do that suppression, BTW. I was very confused when I couldn't find the compiler invocation in gdb.log, and it took me a while to notice that code. The reason get_compiler_info in parallel mode isn't hitting the cache is that in that mode each testcase runs under its own expect/dejagnu process, and the way get_compiler_info caches results currently doesn't handle that -- the result is simply cached in a global variable, which is private to each expect. So improve this by switching get_compiler_info's caching mechanism to gdb_caching_proc instead, so that results are cached across parallel invocations of dejagnu. On an x86-64 GNU/Linux run with "make check-parallel -j32", before the patch I get 2223 calls to get_compiler_info that result in a compiler invocation. After the patch, I get 7. On GNU/Linux, those compiler invocations don't cost much, but on Windows, they add up. On my machine each invocation takes around 500ms to 700ms. Here is one representative run: $ time x86_64-w64-mingw32-gcc \ /c/msys2/home/alves/gdb/build-testsuite/temp/14826/compiler.c \ -fdiagnostics-color=never -E ... real 0m0.639s user 0m0.061s sys 0m0.141s This reference to a 'compiler_info' global: # N.B. compiler_info is intended to be local to this file. # Call test_compiler_info with no arguments to fetch its value. # Yes, this is counterintuitive when there's get_compiler_info, # but that's the current API. if [info exists compiler_info] { unset compiler_info } is outdated, even before this patch, as "compiler_info" is a local variable in get_compiler_info. Remove all that code. Since test_compiler_info now calls get_compiler_info directly, the "Requires get_compiler_info" comments in skip_inline_frame_tests and skip_inline_var_tests are no longer accurate. Remove them. test_compiler_info's intro comment is also outdated; improve it. Changing the return value of get_compiler_info to be the 'compiler_info' string directly instead of 0/-1 was simpler. It would be possible to support the current 0/-1 interface by making get_compiler_info_1 still return the 'compiler_info' string, and then having the get_compiler_info wrapper convert to 0/-1, and I considered doing that. But the only caller of get_compiler_info outside gdb.exp is gdb.python/py-event-load.exp, and it seems that one simply crossed wires with: commit 9704b8b4bc58f4f464961cca97d362fd33740ce8 gdb/testsuite: remove unneeded calls to get_compiler_info as the test as added at roughly the same time as that commit. So simply remove that call in gdb.python/py-event-load.exp, otherwise we get something like: ERROR: ------------------------------------------- ERROR: in testcase src/gdb/testsuite/gdb.python/py-event-load.exp ERROR: expected boolean value but got "gcc-13-3-0" ERROR: tcl error code TCL VALUE NUMBER ERROR: tcl error info: expected boolean value but got "gcc-13-3-0" Approved-By: Tom Tromey <tom@tromey.com> Change-Id: Ia3d3dc34f7cdcf9a2013f1054128c62a108eabfb
3 daysRemove uses of "eval" from gdb testsuiteTom Tromey7-29/+29
This patch removes a lot of uses of the Tcl "eval" proc from the gdb test suite. In most cases the {*} "splat" expansion is used instead. A few uses of eval remain, primarily ones that were more complicated to untangle. In a couple of tests I also replaced some ad hoc code with string_to_regexp. Tested on x86-64 Fedora 40. Reviewed-By: Tom de Vries <tdevries@suse.de>
5 days[gdb/testsuite, tclint] Fix lib/tuiterm.expTom de Vries1-4/+4
Running tclint on lib/tuiterm.exp shows a few problems: ... $ tclint --ignore line-length gdb/testsuite/lib/tuiterm.exp tuiterm.exp:105:3: expression with substitutions should be enclosed by \ braces [unbraced-expr] tuiterm.exp:1576:28: unnecessary command substitution within expression \ [redundant-expr] tuiterm.exp:1582:25: unnecessary command substitution within expression \ [redundant-expr] ... Fix these. Tested on aarch64-linux.
6 days[gdb/testsuite, tclint] Drop lreverseTom de Vries1-13/+0
When running tclint with lib/future.exp, I get: ... $ tclint lib/future.exp $exp:756:5: redefinition of built-in command 'lreverse' [redefined-builtin] ... The code was added to handle pre-7.5 tcl versions without lreverse. Since we now require Tcl 8.6.2 (as per PR testsuite/33205), drop this. Tested by rerunning tclint. Approved-By: Simon Marchi <simon.marchi@efficios.com> PR testsuite/33403 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33403
9 daysRequire Tcl 8.6.2Tom Tromey1-44/+1
This changes the gdb test suite to require Tcl 8.6.2. This allows the removal of some more compatibility code. I wrote this as a separate patch so make it simpler to drop if some platform only provides Tcl 8.5. According to research in the bug, though, it seems like this isn't likely. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33205 Approved-By: Simon Marchi <simon.marchi@efficios.com>
9 daysRewrite tcl_version_at_leastTom Tromey1-15/+3
tcl_version_at_least can more easily be expressed using the built-in "package" command. Approved-By: Simon Marchi <simon.marchi@efficios.com>
9 daysRequire Tcl 8.5Tom Tromey1-17/+2
This patch changes the gdb test suite to require Tcl 8.5. It also removes the one pre-8.5 compatibility function. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33205 Approved-By: Simon Marchi <simon.marchi@efficios.com>
10 days[gdb/testsuite] Error out on clean_restart <absolute filename>Tom de Vries2-0/+7
Error out in proc clean_restart if the argument is an absolute filename. Likewise in proc mi_clean_restart. Tested on x86_64-linux.
12 days[gdb/testsuite] Fix clean_restart <absolute filename> in allow_aarch64_sme_testsTom de Vries1-1/+2
Fix fallout on aarch64-linux with test-case gdb.testsuite/gdb-caching-proc-consistency.exp from erroring out on clean_restart <absolute filename>.
12 days[gdb/testsuite] Fix silent timeout in allow_aarch64_gcs_testsTom de Vries1-0/+3
I noticed on M1 aarch64-linux that test-case gdb.testsuite/gdb-caching-proc-consistency.exp took a long time. I saw lack of progress in gdb.log for proc allow_aarch64_gcs_tests. This gdb_expect only handles the case that gcs support is detected: ... gdb_expect { -re ".*$inferior_exited_re normally.*${gdb_prompt} $" { verbose -log "\n$me: gcs support detected" set allow_gcs_tests 1 } } ... but in my case, I get: ... (gdb) run ^M Starting program: allow_aarch64_gcs_tests.x ^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M [Inferior 1 (process 3336556) exited with code 01]^M (gdb) ... so the gdb_expect times out quietly, taking 10 seconds. In the test-case, it does so 11 times. Fix this by adding a gdb_expect clause handling the "with code 01" case. Tested on aarch64-linux. PR testsuite/33378 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33378
13 daysGDB: aarch64-linux: Define HWCAP_GCS as unsigned long long valueThiago Jung Bauermann1-1/+1
On platforms where long is 32 bits, this change fixes a build failure: /home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c: In function ‘const target_desc* aarch64_linux_core_read_description(gdbarch*, target_ops*, bfd*)’: /home/linux/arm/gdb/src/gdb/arch/aarch64-gcs-linux.h:27:24: error: left shift count >= width of type [-Werror=shift-count-overflow] 27 | #define HWCAP_GCS (1UL << 32) | ~~~~^~~~~ /home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c:1714:47: note: in expansion of macro ‘HWCAP_GCS’ 1714 | features.gcs = features.gcs_linux = hwcap & HWCAP_GCS; | ^~~~~~~~~ Suggested-by: Tom de Vries <tdevries@suse.de> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33372
13 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/aarch64*.expTom de Vries1-2/+4
Fix clean_restart <absolute filename> in gdb.arch/aarch64*.exp. Tested on aarch64-linux, M1 system. There's a large number (44) of unsupported, for the following reasons: - allow_aarch64_gcs_tests - allow_aarch64_mops_tests - allow_aarch64_sve_tests / target does not support SVE - memory tagging unsupported Consequently, we mostly use the simple substitution: ... clean_restart $binfile -> clean_restart gdb_load $binfile ...
2025-09-02[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.reverseTom de Vries1-1/+2
Fix clean_restart <absolute filename> in the test-cases in gdb.reverse. Tested on: - x86_64-linux, target boards unix and unix/-m32 - aarch64-linux - ppc64le-linux - s390x-linux
2025-09-02[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.testsuiteTom de Vries2-7/+14
Fix clean_restart <absolute filename> in the test-cases in gdb.testsuite. Tested on x86_64-linux.
2025-09-02Fix host_file_normalize_mingwPedro Alves1-2/+24
Tom de Vries ran the testsuite on msys2-ucrt64 with mount point map: ... /bin C:/msys64/usr/bin /c C: / C:/msys64 ... and ran into the problem that host_file_normalize didn't translate: ... /home/user/gdb/build/gdb/testsuite/temp/n/x ... into: ... C:/msys64/home/user/gdb/build/gdb/testsuite/temp/n/x ... The problem is that host_file_normalize_mingw mishandles a file/directory under the root mount point. A simpler reproducer is "/foo". If we add that as a test to gdb.testsuite/mount-point-map.exp, we see: input: /foo expected: C:/msys64/foo/ got: /foo FAIL: gdb.testsuite/mount-point-map.exp: /foo For a mount point that ends in /, this line in host_file_normalize_mingw: } elseif {[string index $filename $mount_len] eq "/"} { ... is always false, because the character at $mount_len is the one _after_ the slash. Notice that the "/" mount point is the only one that ends in "/". This is even if you try to create one explicitly with a trailing /. On MSYS2: $ mount c:/foo /foo/ mount: warning - /foo/ does not exist. $ mount C:/foo on /foo type ntfs (binary,user) ... So fix this by special casing the "/" mount point. And then... while playing with fixing this, I noticed I had done something strange with this case: if {[string length $filename] == $mount_len} { return "$win_filename/" The intent was to append the slash when the mount is a drive letter, like 'cygpath -ma' does: $ cygpath -ma /c C:/ Other cases do not get a trailing slash: $ cygpath -ma /c/foo C:/foo I think this is because on Windows, every drive letter has a current directory, and really "C:" means "current directory of drive letter C:", not "root of C:". Resolving it to "C:/" makes it unambiguous. However, I mishandled that in a63213cd374d ('MSYS2+MinGW testing: Unix <-> Windows path conversion'). The original version of that patch when I posted it to the mailing list only supported drive mounts, which turned out incorrect, and then I generalized it to work with all mount points before it was merged. In the process, I inadvertently made the code append the slash whenever the input filename matches a mount exactly, any mount. I also now noticed that TCL's "file normalize" on Linux always removes the trailing slash, and since host_file_normalize is an abstraction for it, I think host_file_normalize_mingw should do the same. Likewise for duplicate slashes, "file normalize" gets rid of them. Fix all this in host_file_normalize_mingw, and add corresponding tests to gdb.testsuite/mount-point-map.exp. I smoke tested this here with a few of the testcases that required tweaking in the patch that added host_file_normalize, like gdb.base/source-dir.exp and gdb.base/fullname.exp and they still pass. Tom ran gdb.testsuite/mount-point-map.exp on both x86_64-linux and msys2-ucrt64, and it passed in both cases. Change-Id: I852a8662f0cb8b0ee4e683e9b157618cf6955477
2025-09-02Add gdb.testsuite/mount-point-map.expTom de Vries1-22/+32
Proc host_file_normalize is structured like this: ... proc host_file_normalize {filename} { if {[ishost *-*-mingw*]} { ... } return [file normalize $filename] ... so a testcase exercising the mingw specific part can only be run on a mingw host. Factor out a new proc host_file_normalize_mingw, which can be used on any host platform. Add testcase gdb.testsuite/mount-point-map.exp, exercising host_file_normalize_mingw. Tested on aarch64-linux, x86-64-linux, msys2-ucrt64, and msys2-mingw. Co-Authored-By: Pedro Alves <pedro@palves.net> Change-Id: Ia130de5c12c940852b6367c422d04896863bfc02
2025-08-29GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack supportThiago Jung Bauermann1-0/+51
Add the org.gnu.gdb.aarch64.gcs feature with the GCSPR register, and the org.gnu.gdb.aarch64.gcs.linux feature with "registers" to represent the Linux kernel ptrace and prctl knobs that enable and lock specific GCS functionality. This code supports GCS only in Linux userspace applications, so the GCSPR that is exposed is the one at EL0. Also, support for calling inferior functions is enabled by adding an implementation for the shadow_stack_push gdbarch method. If for some reason a target description contains the org.gnu.gdb.aarch64.gcs feature but not the org.gnu.gdb.aarch64.gcs.linux feature then GCS support is disabled and GDB continues the debugging session. Features that need GCS support (for example, calling inferior functions) will not work and the inferior will get a segmentation fault signal instead. There's a testcase for this scenario but it only checks the native debugging case, even though in practice this problem would only occur in remote debugging with a broken stub or gdbserver. I tested manually with a gdbserver hacked to send a broken target description and it worked as described. Testcases gdb.arch/aarch64-gcs.exp, gdb.arch/aarch64-gcs-core.exp and gdb.arch/aarch64-gcs-wrong-tdesc.exp are included to cover the added functionality. Reviewed-By: Christina Schimpe <christina.schimpe@intel.com> Approved-By: Luis Machado <luis.machado@arm.com>
2025-08-29gdb, gdbserver: Add support of Intel shadow stack pointer register.Christina Schimpe1-0/+70
This patch adds the user mode register PL3_SSP which is part of the Intel(R) Control-Flow Enforcement Technology (CET) feature for support of shadow stack. For now, only native and remote debugging support for shadow stack userspace on amd64 linux are covered by this patch including 64 bit and x32 support. 32 bit support is not covered due to missing Linux kernel support. This patch requires fixing the test gdb.base/inline-frame-cycle-unwind which is failing in case the shadow stack pointer is unavailable. Such a state is possible if shadow stack is disabled for the current thread but supported by HW. This test uses the Python unwinder inline-frame-cycle-unwind.py which fakes the cyclic stack cycle by reading the pending frame's registers and adding them to the unwinder: ~~~ for reg in pending_frame.architecture().registers("general"): val = pending_frame.read_register(reg) unwinder.add_saved_register(reg, val) return unwinder ~~~ However, in case the python unwinder is used we add a register (pl3_ssp) that is unavailable. This leads to a NOT_AVAILABLE_ERROR caught in gdb/frame-unwind.c:frame_unwind_try_unwinder and it is continued with standard unwinders. This destroys the faked cyclic behavior and the stack is further unwinded after frame 5. In the working scenario an error should be triggered: ~~~ bt 0 inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:49^M 1 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M 2 0x000055555555516e in inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M 3 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M 4 0x000055555555516e in inline_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:45^M 5 normal_func () at /tmp/gdb.base/inline-frame-cycle-unwind.c:32^M Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5 ~~~ To fix the Python unwinder, we simply skip the unavailable registers. Also it makes the test gdb.dap/scopes.exp fail. The shadow stack feature is disabled by default, so the pl3_ssp register which is added with my CET shadow stack series will be shown as unavailable and we see a TCL error: ~~ >>> {"seq": 12, "type": "request", "command": "variables", "arguments": {"variablesReference": 2, "count": 85}} Content-Length: 129^M ^M {"request_seq": 12, "type": "response", "command": "variables", "success": false, "message": "value is not available", "seq": 25}FAIL: gdb.dap/scopes.exp: fetch all registers success ERROR: tcl error sourcing /tmp/gdb/testsuite/gdb.dap/scopes.exp. ERROR: tcl error code TCL LOOKUP DICT body ERROR: key "body" not known in dictionary while executing "dict get $val body variables" (file "/tmp/gdb/testsuite/gdb.dap/scopes.exp" line 152) invoked from within "source /tmp/gdb/testsuite/gdb.dap/scopes.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source /tmp/gdb/testsuite/gdb.dap/scopes.exp" invoked from within "catch "uplevel #0 source $test_file_name" msg" UNRESOLVED: gdb.dap/scopes.exp: testcase '/tmp/gdb/testsuite/gdb.dap/scopes.exp' aborted due to Tcl error ~~ I am fixing this by enabling the test for CET shadow stack, in case we detect that the HW supports it: ~~~ # If x86 shadow stack is supported we need to configure GLIBC_TUNABLES # such that the feature is enabled and the register pl3_ssp is # available. Otherwise the reqeust to fetch all registers will fail # with "message": "value is not available". if { [allow_ssp_tests] } { append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK" } ~~~ Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-08-29gdb, testsuite: Extend core_find procedure to save program output.Christina Schimpe1-2/+8
From: Thiago Jung Bauermann <thiago.bauermann@linaro.org> The change comes from ARM's GCS series: [PATCH v3 5/9] GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack support. We need it for testing coredump files, too. So include it in this patch series. Abridged-by: Christina Schimpe <christina.schimpe@intel.com> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Andrew Burgess <aburgess@redhat.com> --- This is the patch mentioned above: https://sourceware.org/pipermail/gdb-patches/2025-June/218892.html Minus everything except for the change in gdb.exp's corefind procedure.
2025-08-27gdb/testsuite: get real executable in gdb.gdb/index-file.expSimon Marchi1-9/+37
Similar to a previous patch, if the gdb executable is in fact a libtool wrapper, we need to get the path to the real executable to load it in the top-level gdb. With this change, the test runs on Cygwin, although I do see two failures: FAIL: gdb.gdb/index-file.exp: debug_names files are identical FAIL: gdb.gdb/index-file.exp: debug_str files are identical Change-Id: Ie06d1ece67e61530e5b664e65b5ef0edccaf6afa Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-08-27gdb/testsuite: turn thread events off in selftestsSimon Marchi1-0/+4
When running gdb.gdb/selftest.exp on Cygwin, the test eventually times out on this command: (gdb) PASS: gdb.gdb/selftest.exp: printed version as pointer continue Continuing. [New Thread 4804.0x1728] [New Thread 4804.0x2f24] [New Thread 4804.0x934] [New Thread 4804.0x23a8] [New Thread 4804.0x2cf4] [New Thread 4804.0x1408] [New Thread 4804.0x2c90] [New Thread 4804.0xc58] [New Thread 4804.0x1d40] [New Thread 4804.0x1824] GNU gdb (GDB) 17.0.50.20250530-git Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) [New Thread 4804.0x2c64] [New Thread 4804.0x23c4] [New Thread 4804.0x2814] [Thread 4804.0x1200 exited with code 0] [Thread 4804.0x293c exited with code 0] [Thread 4804.0x2c9c exited with code 0] FAIL: gdb.gdb/selftest.exp: xgdb is at prompt (timeout) The problem is the new thread notification, and the fact that the test expects the prompt to be the last thing in the buffer. To avoid the thread events interfering with the test, disable them, they are not useful here. With this patch, gdb.gdb/selftest.exp mostly runs fine on Cygwin, the only remaining problem appears to be: (gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process signal SIGINT Continuing with signal SIGINT. PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process, top GDB message FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process, bottom GDB message (timeout) Change-Id: I0b1df0503c1961c042c8de559b4d223c5d3cb95c Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-08-27gdb/testsuite: use libtool to launch selftestsSimon Marchi1-17/+87
When building GDB on Cygwin, gdb/gdb.exe is a libtool wrapper (which happens to be a PE executable). The real executable is at gdb/.libs/gdb.exe. The "does gdb have debug info test" that _selftest_setup does is bogus, because it loads the libtool wrapper (which doesn't have debug info), doesn't see any debug info, and thus the test is skipped. The "correct" way to deal with libtool wrappers is to run the shell command you want to run under `libtool --mode=execute`. That will replace any path resembling to a libtool wrapper with the real executable path. But it will also add to the environment the library paths necessary for this executable to find the libraries it needs. Therefore, modify the `do_self_tests` proc to: - run the top-level GDB commands under `libtool --mode=execute` - pass the path to the inferior GDB on the command-line of the top-level, so that it gets replaced with the real executable's path However, the "file" command was previously used to detect the presence of debug info in the GDB executable. It's not easy to implement this check when loading the executable directly on the command line. So, add a separate proc, _selftest_check_executable_debug_info, that spawns a temporary GDB and does the debug info check through the file command. This proc uses libtool to obtain the path to the real executable. When building, we use the bundled libtool.m4 at the top of the tree. This means that the libtool system package, and therefore the libtool binary, might not be available. Check for the presence of the libtool binary first, and only do the conversion if it is found. If it is not found, the test should still work on platforms that don't require the conversion. With this commit, the test runs on Cygwin, even though there are failures later. Change-Id: Ie7b712cdc84671a5a017655a7e41687ff23f906c Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-08-27gdb/testsuite: do not copy gdb executable in self testsSimon Marchi1-21/+2
In the ROCm-GDB testing process, we hit a problem that is a combination of these 3 factors: 1. In the downstream ROCm-GDB packages, the gdb executable is built with a relative RUNPATH: 0x000000000000001d (RUNPATH) Library runpath: [${ORIGIN}/../lib] This is done so that the installation is relocatable (the whole ROCm directory can be copied around) and things still work. For instance, the rocgdb executable needs to be able to find the libraries it needs, such as `librocm-dbgapi.so.0`. The relative runpath allows that. 2. For testing, we run the testsuite against the gdb executable installed from one of those packages. It is possible to ./configure the testsuite directory on its own, and then do: $ make check RUNTESTFLAGS="GDB=/opt/rocm/bin/rocgdb" 3. The selftests (such as gdb.gdb/selftest.exp) copy the GDB under test to the standard output directory, before trying to debug it. The problem is that the gdb executable under test that has been copied can't find the libraries it needs. With this patch, I propose that we don't copy the gdb executable, but debug it in place instead. The comment removed in this patch says "in case this OS doesn't like to edit its own text space", and has been there since forever in some form. But it's not clear if there is a host OS (where we intend to run this test) that needs this nowadays. I would bet that there isn't. If there is in fact a GDB host OS (where we intend to run this test) that needs it, we can reinstate the copying, but as an opt-in operation. Another situation where this change helps is on Windows, where gdb/gdb.exe is a libtool wrapper (the real executable is at gdb/.libs/gdb.exe). Copying gdb/gdb.exe doesn't accomplish anything useful. The next patch does further changes to account for the libtool wrapper case. I tested on Linux and Cygwin, more testing would be welcome. Change-Id: Id4148517d4fc4ecdd49f099c12003e3d16c6a93d Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-08-27gdb/testsuite: remove function parameter from do_self_testsSimon Marchi1-6/+5
The function to stop at is always main. Remove the parameter and hard-code main in _selftest_setup. Change-Id: Ibbbf598203b1658305eb6bc631d029652c10edac Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-08-27gdb/testsuite: namespace procs in lib/selftest-support.expSimon Marchi1-5/+5
Rename some procs in lib/selftest-support.exp that are only used internally, to make it a bit clearer that they are just internal helpers. Change-Id: Icd399ac42698209fbc8e798bf43a7d8464aa848c Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-08-27[gdb/testsuite] Add have_startup_shellTom de Vries1-0/+41
Say we disable startup-with-shell, we get: ... (gdb) run `echo 8`^M Starting program: a2-run `echo 8`^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M usage: factorial <number>^M [Inferior 1 (process 10787) exited with code 01]^M (gdb) FAIL: gdb.base/a2-run.exp: run "a2-run" with shell (timeout) ... Fix this by only doing this test if startup-with-shell is supported. This fixes the test-case on msys2-ucrt64, where startup-with-shell is not supported. Likewise in other test-cases. Tested on x86_64-linux.
2025-08-22MSYS2+MinGW testing: Unix <-> Windows path conversionPedro Alves1-11/+200
On an MSYS2 system, I have: # which tclsh /mingw64/bin/tclsh # which tclsh86 /mingw64/bin/tclsh86 # which tclsh8.6 /usr/bin/tclsh8.6 # which expect /usr/bin/expect The ones under /usr/bin are MSYS2 programs (linked with msys-2.0.dll). I.e., they are really Cygwin (unix) ports of the programs. The ones under /mingw64 are native Windows programs (NOT linked with msys-2.0.dll). You can check that with CYGWIN/MSYS2 ldd. The MSYS2/Cygwin port of TCL (and thus expect) does not treat a file name that starts with a drive letter as an absolute file name, while the native/MinGW port does. Vis: # cat file-join.exp puts [file join c:/ d:/] # /mingw64/bin/tclsh.exe file-join.exp d:/ # /mingw64/bin/tclsh86.exe file-join.exp d:/ # /usr/bin/expect.exe file-join.exp c:/d: # /usr/bin/tclsh8.6.exe file-join.exp c:/d: When running the testsuite under MSYS2 to test mingw32 (Windows native) GDB, we use MSYS2 expect (there is no MinGW port of expect AFAIK). Any TCL file manipulation routine will thus not consider drive letters special, and just treats them as relative file names. This results in several cases of the testsuite passing to GDB broken file names, like: "C:/foo/C:/foo/bar" or: "/c/foo/C:/foo/bar" E.g., there is a "file join" in standard_output_file that results in this: (gdb) file C:/gdb/build/outputs/gdb.base/info_sources_2/C:/gdb/build/outputs/gdb.base/info_sources_2/info_sources_2 C:/gdb/build/outputs/gdb.base/info_sources_2/C:/gdb/build/outputs/gdb.base/info_sources_2/info_sources_2: No such file or directory. (gdb) ERROR: (info_sources_2) No such file or directory delete breakpoints The bad "file join" comes from clean_restart $binfile, where $binfile is an absolute host file name (thus has a drive letter), clean_restart doing: set binfile [standard_output_file ${executable}] return [gdb_load ${binfile}] and standard_output_file doing: # If running on MinGW, replace /c/foo with c:/foo if { [ishost *-*-mingw*] } { set dir [exec sh -c "cd ${dir} && pwd -W"] } return [file join $dir $basename] Here, BASENAME was already an absolute file name that starts with a drive letter, but "file join" treated it as a relative file name. Another spot where we mishandle Unix vs drive letter file names, is in the "dir" command that we issue when starting every testcase under GDB. We currently always pass the file name as seen from the build machine (i.e., from MSYS2), which is a Unix file name that native Windows GDB does not understand, resulting in: (gdb) dir /c/gdb/src/gdb/testsuite/gdb.rocm warning: /c/gdb/src/gdb/testsuite/gdb.rocm: No such file or directory Source directories searched: /c/gdb/src/gdb/testsuite/gdb.rocm;$cdir;$cwd This patch introduces a systematic approach to handle all this, by introducing the concepts of build file names (what DejaGnu sees) vs host file names (what GDB sees). This patches implements that in the following way: 1) - Keep standard_output_file's host-side semantics standard_output_file currently converts the file name to a Windows file name, using the "cd $dir; pwd -W" trick. standard_output_file is used pervasively, so I think it should keep the semantics that it returns a host file name. Note there is already a preexisting host_standard_output_file procedure. The difference to standard_output_file is that host_standard_output_file handles remote hosts, while standard_output_file assumes the build and host machines share a filesystem. The MSYS2 Unix path vs MinGW GDB drive letter case fall in the "shared filesystem" bucket. An NFS mount on the host at the same mount point as on the build machine falls in that bucket too. 2) - Introduce build_standard_output_file In some places, we are calling standard_output_file to find the build-side file name, most often just to find the standard output directory file name, and then immediately use that file name with TCL file manipulation procedures, to do some file manipulation on the build machine. clean_standard_output_dir is an example of such a case. That code path is responsible for this bogus 'rm -rf' in current MSYS2 testing: Running /c/gdb/src/gdb/testsuite/gdb.base/break.exp ... Executing on build: rm -rf /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-tests... For these cases, add a variant of standard_output_file called build_standard_output_file. The main difference to standard_output_file is that it doesn't do the "cd $dir; pwd -W" trick. I.e., it returns a path on the build machine. 3) Introduce host_file_sanitize In some cases, we read an absolute file name out of GDB's output, and then want to compare it against some other file name. The file name may originally come from the DWARF, and sometimes may have forward slashes, and other times, it may have backward slashes. Or the drive letter may be uppercase, or it may be lowercase. To make comparisons easier, add a new host_file_sanitize procedure, that normalizes slashes, and uppercases the drive letter. It does no other normalization. Particularly, it does not turn a relative file name into an absolute file name. It's arguable whether GDB itself should do this sanitization. I suspect it should. I personally dislike seeing backward slashes in e.g., "info shared" output, or worse, mixed backward and forward slashes. Still, I propose starting with a testsuite adjustment that moves us forward, and handle that separately. I won't be surprised if we need the new routine for some cases even if we adjust GDB. 4) build_file_normalize / host_file_normalize In several places in the testsuite, we call "file normalize" on some file name. If we pass it a drive-letter file name, that TCL procedure treats the passed in file name as a relative file name, so produces something like /c/foo/C:/foo/bar.txt. If the context calls for a build file name, then the "file normalize" call should produce /c/foo/bar.txt. If OTOH we need a host file name, then it should produce "C:/foo/bar.txt". Handle this by adding two procedures that wrap "file normalize": - build_file_normalize - host_file_normalize Initialy I implemented them in a very simple way, calling into cygpath: proc build_file_normalize {filename} { if { [ishost *-*-mingw*] } { return [exec cygpath -ua $filename] } else { return [file normalize $filename] } } proc host_file_normalize {filename} { if { [ishost *-*-mingw*] } { return [exec cygpath -ma $filename] } else { return [file normalize $filename] } } "cygpath" is a utility that comes OOTB with both Cygwin and MSYS2, that does Windows <-> Cygwin file name conversion. This works well, but because running the testsuite on Windows is so slow, I thought of trying to avoid or minimize the cost of calling an external utility ("cygpath"). On my system, calling into cygpath takes between 200ms to 350ms, and these smallish costs (OK, not so small!) can creep up and compound an already bad situation. Note that the current call to "cd $dir; pwd -W" has about the same cost as a "cygpath" call (though a little bit cheaper). So with this patch, we actually don't call cygpath at all, and no longer use the "cd $dir; pwd -W" trick. Instead we run the "mount" command once, and cache the mapping (via gdb_caching_proc) between Windows file names and Unix mount points, and then use that mapping in host_file_normalize and build_file_normalize, to do the Windows <=> Unix file name conversions ourselves. One other small advantage here is that this approach works the same for 'cygwin x mingw' testing [1], and 'msys x mingw' testing, while "pwd -W" only works on MSYS2. So I think the end result is that we should end up faster (or less slow) than the current state. (No, I don't have actual timings for the effect over a whole testsuite run.) 5) Introduce host_file_join For the "file join" call done from within standard_output_file (and probably in future other places), since that procedure works with host file names, add a new host_file_join procedure that is a wrapper around "file join" that is aware of Windows drive letters. ====== With the infrastructure described above in place, the "dir" case is fixed by simply calling host_file_normalize on the directory name, before passing it to GDB. That turns: (gdb) dir /c/gdb/src/gdb/testsuite/gdb.base warning: /c/gdb/src/gdb/testsuite/gdb.base: No such file or directory Source directories searched: /c/gdb/src/gdb/testsuite/gdb.base;$cdir;$cwd Into: (gdb) dir C:/gdb/src/gdb/testsuite/gdb.base Source directories searched: C:/gdb/src/gdb/testsuite/gdb.base;$cdir;$cwd Running the testsuite on GNU/Linux reveals that that change requires tweaks to gdb.guile/scm-parameter.exp and gdb.python/py-parameter.exp, to run the expected directory by host_file_normalize too, so that it matches the directory we initially pass GDB at startup time. Without that fix, there could be a mismatch if the GDB sources path has a symlink component, which now gets resolved by the host_file_normalize call. The theory is that most standard_output_file uses will not need to be adjusted. I grepped for "file normalize" and "file join", to find cases that might need adjustment, and fixed those that required fixing. The fixes are included in this patch, to make it easier to reason about the overall change. E.g., in gdb.base/fullname.exp, without the fix, we get: Running /c/gdb/src/gdb/testsuite/gdb.base/fullname.exp ... ERROR: tcl error sourcing /c/gdb/src/gdb/testsuite/gdb.base/fullname.exp. ERROR: tcl error code NONE ERROR: C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/fullname/tmp-fullname.c not a subdir of /c/msys2/home/alves/gdb/build-testsuite In gdb.base/source-dir.exp, we have several issues. E.g., we see the "/c/foo/c:/foo" problem there too: dir /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/source-dir/C:/msys2/home/alves/gdb/build-testsuite/outputs warning: /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/source-dir/C:/msys2/home/alves/gdb/build-testsuite/outputs: No such file or directory Source directories searched: /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/source-dir/C:/msys2/home/alves/gdb/build-testsuite/outputs;$cdir;$cwd (gdb) PASS: gdb.base/source-dir.exp: setup source path search directory ... Executing on host: x86_64-w64-mingw32-gcc \ -fno-stack-protector \ /c/msys2/home/alves/gdb/build-testsuite/C:/msys2/home/alves/gdb/build-testsuite/outputs/gdb.base/macro-source-path/cwd/macro-source-path.c ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... and we need to handle Unix file names that we pass to the compiler (on the build side), vs file names that GDB prints out (the host side). Similarly in the other testcases. I haven't yet tried to do a full testsuite run on MSYS2, and I'm quite confident there will be more places that will need similar adjustment, but I'd like to land the infrastructure early, so that the rest of the testsuite can be adjusted incrementally, and others can help. Change-Id: I664dbb86d0efa4fa8db405577bea2b4b4a96a613
2025-08-22testsuite: Introduce gdb_watchdog (avoid unistd.h/alarm)Pedro Alves2-1/+89
There are a good number of testcases in the testsuite that use alarm() as a watchdog that aborts the test if something goes wrong. alarm()/SIG_ALRM do not exist on (native) Windows, so those tests fail to compile there. For example, testing with x86_64-w64-mingw32-gcc, we see: Running /c/rocgdb/src/gdb/testsuite/gdb.base/attach.exp ... gdb compile failed, C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c: In function 'main': C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c:17:3: error: implicit declaration of function 'alarm' [-Wimplicit-function-declaration] 17 | alarm (60); | ^~~~~ While testing with a clang configured to default to x86_64-pc-windows-msvc, which uses the C/C++ runtime headers from Visual Studio and has no unistd.h, we get: Running /c/rocgdb/src/gdb/testsuite/gdb.base/attach.exp ... gdb compile failed, C:/rocgdb/src/gdb/testsuite/gdb.base/attach.c:8:10: fatal error: 'unistd.h' file not found 8 | #include <unistd.h> | ^~~~~~~~~~ Handle this by adding a new testsuite/lib/gdb_watchdog.h header that defines a new gdb_watchdog function, which wraps alarm on Unix-like systems, and uses a timer on Windows. This patch adjusts gdb.base/attach.c as example of usage. Testing gdb.base/attach.exp with clang/x86_64-pc-windows-msvc required a related portability tweak to can_spawn_for_attach, to not rely on unistd.h on Windows. gdb.rocm/mi-attach.cpp is another example adjusted, one which always runs with clang configured as x86_64-pc-windows-msvc on Windows (via hipcc). Approved-by: Kevin Buettner <kevinb@redhat.com> Change-Id: I3b07bcb60de039d34888ef3494a5000de4471951
2025-08-22Automatically handle includes in testsuite/lib/Pedro Alves1-0/+63
Instead of manually calling lappend_include_file in every testcase that needs to include a file in testsuite/lib/, handle testsuite/lib/ includes automatically in gdb_compile. As an example, gdb.base/backtrace.exp is adjusted to no longer explicitly call lappend_include_file for testsuite/lib/attributes.h. Tested on x86-64 GNU/Linux with both: $ make check RUNTESTFLAGS=" \ --host_board=local-remote-host-native \ --target_board=local-remote-host-native \ HOST_DIR=/tmp/foo/" \ TESTS="gdb.base/backtrace.exp" and: $ make check TESTS="gdb.base/backtrace.exp" and confirming that the testcase still compiles and passes cleanly. Also ran full testsuite on x86-64 GNU/Linux in normal mode. Approved-by: Kevin Buettner <kevinb@redhat.com> Change-Id: I5ca77426ea4a753a995c3ad125618c02cd952576
2025-08-16[gdb/testsuite] Fix TUI tests on freebsdTom de Vries1-10/+16
While re-testing the TUI tests on x86_64-freebsd, I found that commit 06a53717f7c ("[gdb/testsuite] Handle unrecognized escape sequences better in tuiterm") broke most test-cases. Fix this by rewriting this gdb_test_multiple clause: ... -re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" { ... into: ... -re "^($re_csi_cmd)" { ... -re "^($re_csi_args*)($re_csi_cmd)" { ... -re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" { ... Tested on x86_64-linux and x86_64-freebsd.
2025-08-16[gdb/testsuite] Handle unrecognized escape sequences better in tuitermTom de Vries1-17/+66
When encountering an unrecognized escape sequence in Term::accept_gdb_output, a warning is issued: ... WARNING: timeout in accept_gdb_output ... and 0 is returned. Subsequent calls run into the same problem, so matching doesn't progress. Consequently, figuring out what the unrecognized escape sequence actually is depends on analyzing gdb's output as echoed into gdb.log. In the test added in this commit, gdb (well, a script gdb.tcl emulating gdb) outputs escape sequence "ESC ( B", which doesn't show up in recognizable form in gdb.log: ... foo^M^M ... and as mentioned the tuiterm screen only show: ... foo ... because matching doesn't progress beyond the unrecognized sequence. Fix this by rewriting accept_gdb_output to match gdb output using a phased approach that echoes unmatched escape sequences, giving us instead on the tuiterm screen: ... foo^[(B ... [ Since "ESC ( B" is now supported, the test-case has been updated to use "ESC ( % 5" instead. ] Tested on x86_64-linux. PR testsuite/33218 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33218
2025-08-16[gdb/testsuite] Move setting of Term::_last_char to Term::_insertTom de Vries1-2/+3
The variable Term::_last_char is meant to represent the last char inserted by Term::_insert, but setting it is done alongside the only call to _insert in lib/tuiterm.exp: ... _insert $expect_out(0,string) variable _last_char set _last_char [string index $expect_out(0,string) end] ... Fix this by moving the setting of _last_char to inside _insert. Tested on x86_64-linux.
2025-08-15[gdb/testsuite] Add Term::with_termTom de Vries1-1/+15
Add Term::with_term that allows us to override the default TERM used in tuiterm: ... Term::with_term xterm { Term::clean_restart 12 40 } ...
2025-08-15[gdb/testsuite] Add Term::_esc_0x3d and Term::_esc_0x3eTom de Vries1-0/+19
Add support for: - DECKPAM (Application Keypad) ESC = - DECKPNM (Normal Keypad) ESC >
2025-08-15[gdb/testsuite] Add Term::_esc_0x28_B and Term::_esc_0x28_0Tom de Vries1-0/+20
Add support for: - Designate G0 Character Set, USASCII ESC ( B - Designate G0 Character Set, DEC Special Character and Line Drawing Set ESC ( 0
2025-08-15[gdb/testsuite] Add Term::_csi_rTom de Vries1-0/+7
Add support for: - Set Scrolling Region (DECSTBM) CSI r
2025-08-15[gdb/testsuite] Add Term::_csi_tTom de Vries1-0/+17
Add support for: - Window manipulation (XTWINOPS) CSI t
2025-08-15[gdb/testsuite] Add Term::_csi_0x3f_l and Term::_csi_0x3f_hTom de Vries1-0/+137
Add support for: - DECSET CSI ? h - DECRST CSI ? l
2025-08-15[gdb/testsuite] Add Term::_csi_h and Term::_csi_lTom de Vries1-0/+34
Add support for: - Set Mode (SM) CSI h - Reset Mode (RM) CSI l
2025-08-14[gdb/testsuite] Remove useless indentation in lib/tuiterm.expTom de Vries1-1105/+1105
In lib/tuiterm.exp we have: ... namespace eval Term { variable ... ... } ... with everything within the namespace (which is basically the entire file) indented, which wastes screen space and makes editing more involved. We could maybe fix this by moving the "namespace eval Term" to tuiterm_env, but I don't think it's a good idea to move it out of the file. Another idea is to have the file include itself, wrapped in the namespace: ... if { ![info exists Term::_in_namespace] } { namespace eval Term { # Read the rest of this file, wrapped in this namespace. variable _in_namespace set _in_namespace 1 source $::srcdir/lib/tuiterm.exp unset _in_namespace return } } variable ... ... but this was considered unnecessarily complex. Fix this in the style of lib/ton.tcl and lib/completion-support.exp: - only declare the variables in the namespace, and - define the procs using a Term:: prefix. As a side-effect, this works around an emacs bug that makes editing lib/tuiterm.exp in its current form problematic because the auto-indentation keeps removing required indentation of all but the first proc [1]. Tested on x86_64-linux. [1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg01674.html
2025-08-14[gdb/testsuite] Disable CLI styling by default in Term::prepare_tuiTom de Vries1-0/+4
On x86_64-freebsd, with test-case gdb.tui/main.exp, I ran into a failure to match the output of the file command, for which I submitted a patch [1]. However, after switching to TERM=ansiw for bsd, I could no longer reproduce the problem. Investigation showed that the difference was caused by CLI styling. A command: ... (gdb) file <filename> ... gives an output: ... Reading symbols from <filename>... (gdb) ... On x86_64-linux, with CLI styling I get: ... Reading symbols from ^[[32m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main^[[39m^[[0;10m... ... After disabling CLI styling using "set style enabled off", I simply get: ... Reading symbols from /data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main... ... and run into the same failure as on x86_64-freebsd. The extra csi sequence "^[[32m" causes an additional matching attempt in Term::wait_for, and the way we're currently matching relies on this: ... send_gdb "file [standard_output_file $testfile]\n" gdb_assert { [Term::wait_for "Reading symbols from"] } "file command" ... Make the TUI testsuite more stable and matching more simple by disabling CLI styling by default, and: - fix the resulting fallout in test-cases gdb.tui/main.exp and gdb.tui/new-layout.exp, and - re-enable CLI styling in the one test-case that needs it: gdb.tui/tui-disasm-styling.exp. Tested on x86_64-linux. [1] https://sourceware.org/pipermail/gdb-patches/2025-June/218942.html
2025-08-14[gdb/testsuite] Make prompt matching in Term::wait_for more strictTom de Vries1-8/+24
On x86_64-freebsd, I run into: ... Box Dump (80 x 24) @ (0, 0): 0 (gdb) maint info screen 1 Number of characters gdb thinks are in a line is 90. 2 Number of characters readline reports are in a line is 89. 3 Number of characters curses thinks are in a line is 90. 4 Number of characters environment thinks are in a line is 90 (COLUMNS). 5 Number of lines gdb thinks are in a page is 40. 6 Number of lines readline reports are in a page is 40. 7 Number of lines curses thinks are in a page is 40. 8 Number of lines environment thinks are in a page is 40 (LINES). 9 Readline wrapping mode: readline (terminal is not auto wrap capable, last column 10 . 11 (gdb) tui disable 12 (gdb) tui disable 13 (gdb) maint info screen 14 15 16 17 18 19 20 21 22 23 FAIL: gdb.tui/resize-2.exp: again: curses width 80 ... The problem is that the prompt matching in Term::wait for is not strict enough. It will accept a line: ... (gdb) foo ... as long as the cursor is pointing just after the prompt, like so: ... (gdb) foo ^ ... Fix this by also checking that the line is empty. Tested on x86_64-linux.
2025-08-14[gdb/testsuite] Stop on main in gdb.gdb/{python-helper,selftest}.expTom de Vries1-14/+32
With a gdb build with gcc 15.1.1 and "-O2 -flto=auto -g", I run into: ... UNTESTED: gdb.gdb/selftest.exp: \ Cannot set breakpoint at captured_main, skipping testcase. UNTESTED: gdb.gdb/python-helper.exp: \ Cannot set breakpoint at captured_main, skipping testcase. ... I don't know why we're trying to stop in captured_main. Stopping in main also works, and main is more likely to be present in an lto build. Fix this by using main instead. This requires us to update the expected file name from main.c to gdb.c in selftest_setup. After doing so, we get: ... XFAIL: gdb.gdb/selftest.exp: \ run until breakpoint at main (line numbers scrambled?) XFAIL: gdb.gdb/python-helper.exp: \ run until breakpoint at main (line numbers scrambled?) ... because main is reported to be in run-on-main-thread.c instead of gdb.c: . Breakpoint 1, main (...) at gdb/run-on-main-thread.c:120^M ... This is due to picking the last line entry for pc == 0x455e40 that has is_stmt == true: ... File name Line number Starting address View Stmt gdb/gdb.c: gdb.c 25 0x455e40 x gdb.c 30 0x455e40 1 x gdb/run-on-main-thread.c: run-on-main-thread.c 116 0x455e40 2 x run-on-main-thread.c 120 0x455e40 3 x gdb/gdb.c: gdb.c 25 0x455e40 4 /usr/include/c++/15/bits/std_thread.h: std_thread.h 366 0x455e4b ... While we're at it, update the corresponding gdb_test_multiple in selftest_setup using multi_line and -wrap. Tested on x86_64-linux.
2025-08-08[gdb/testsuite] Initial TERM=ansis support in tuitermTom de Vries1-1/+11
While investigating using TERM=ansiw for freebsd, I also came across TERM=ansis which unlike ansiw is present on both linux and freebsd. Add initial support for TERM=ansi in tuiterm: - handle ansis in Term::_have_bw - add Term::_csi_x to support (well, ignore) DECREQTPARM (Request Terminal Parameters) This is sufficient to make the TUI testsuite pass on x86_64-freebsd.
2025-08-08[gdb/testsuite] Add gdb.base/color-prompt.expTom de Vries1-0/+25
After updating the documentation in commit cf03713dd1c ("[gdb/cli] Document \001 and \002 usage for set prompt"), I started to wonder if I could reproduce the CLI issue described in PR cli/28887 using the TUI. That turned out not to be the case, but I noticed handling of the markers in tui_puts and tui_puts_internal, and no test-case exercising this, so I decided to add this. After doing so in gdb.tui/color-prompt.exp, I realized I could use the same code to test the CLI case. Add test-case gdb.base/color-prompt.exp that shares code with gdb.tui/color-prompt.exp in gdb.tui/color-prompt.exp.tcl. For the CLI case, I was hoping to reproduce the behaviour described in the PR, but it didn't trigger. FTR, I manually reproduced the behaviour and used script to record it. I observed the following sequence after the C-a: - ^M (CR) : go to start of line - ^[[K (EL) : erase line - ^M (CR) : go to start of line - ^[[31m(gdb) ^[[0m : output prompt - some long command : output text - ^M (CR) : go to start of line - ^[[C, 15 times (CUF): cursor forward 15 times giving me: ... (gdb) some long command ^ ... Perhaps we'll trigger this on some other os, or once we start using a different TERM value. Tested on x86_64-linux.
2025-08-05Use '.rs' extension for Rust in gdb_simple_compileTom Tromey1-0/+4
While trying out gccrs, I noticed that gdb_simple_compile does not use the ".rs" extension for Rust sources. This patch fixes the problem, which lets gccrs get a little further in the test suite.
2025-08-05[UI/TUI] Add support for italic and underline ANSI escape sequencesJannik Hartung1-1/+3
The ANSI escape sequence translation layer in TUI mode strips italic or underlined text modes silently. You cannot output text formatted like that using `TuiWindow.write` in Python at the moment. Parse the ANSI escape sequences for italic and underlined text into the `ui_file_style` structure and apply it to the TUI window when applying styles, similar to preserving the bold/dim state already. A script like this shows italic and underlined text correctly now. ```python import gdb class TestTUIWindow: _tui_window: gdb.TuiWindow def __init__(self, tui_window: gdb.TuiWindow) -> None: self._tui_window = tui_window self._tui_window.title = "colors test" def render(self) -> None: self._tui_window.write(""" \x1b[4mThis is underlined.\x1b[24m And normal text. \x1b[3mThis is italic.\x1b[23m And normal text. """, True) gdb.register_window_type("colortest", TestTUIWindow) ``` And launching it with ``` source the_above_script.py tui new-layout test colortest 1 cmd 1 layout test ``` Approved-By: Tom Tromey <tom@tromey.com>
generated by cgit v1.1 at 2025-09-17 12:21:38 +0000