[gdb/testsuite] Require ![is_remote host] for TUI
authorTom de Vries <tdevries@suse.de>
Mon, 13 Mar 2023 16:20:09 +0000 (17:20 +0100)
committerTom de Vries <tdevries@suse.de>
Mon, 13 Mar 2023 16:20:09 +0000 (17:20 +0100)
When running test-case gdb.tui/corefile-run.exp with both host and target board
local-remote-host-native.exp, we run into:
...
FAIL: gdb.tui/corefile-run.exp: load corefile
...
while this passes with USE_TUI=0.

The problem is that the TUI setup code uses "setenv TERM ansi", which has no
effect on remote host.

I can confirm this analysis by working around this problem in
local-remote-host-native.exp like this:
...
-    spawn $RSH -t -l $username $remote $cmd
+    spawn $RSH -t -l $username $remote "export TERM=ansi; $cmd"
...

For now, simply make TUI unsupported for remote host, by returning 0 in
prepare_for_tui.

Tested on x86_64-linux.

gdb/testsuite/lib/tuiterm.exp

index 8a3f7a48acc0188ce5f0042ec15981d51ae0af31..05edfe9a5b1b07d73e5d6fb573748822aebcd5bd 100644 (file)
@@ -792,6 +792,14 @@ namespace eval Term {
     # Setup ready for starting the tui, but don't actually start it.
     # Returns 1 on success, 0 if TUI tests should be skipped.
     proc prepare_for_tui {} {
+       if { [is_remote host] } {
+           # In clean_restart, we're using "setenv TERM ansi", which has
+           # effect on build.  If we have [is_remote host] == 0, so
+           # build == host, then it also has effect on host.  But for
+           # [is_remote host] == 1, it has no effect on host.
+           return 0
+       }
+
        if {![allow_tui_tests]} {
            return 0
        }