[binutils-gdb] [gdb/testsuite] Require ![is_remote host] for TUI

[binutils-gdb] [gdb/testsuite] Require ![is_remote host] for TUI

[Tom de Vries]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=72f160d012233b7a322cd626e11f787f501beee2

commit 72f160d012233b7a322cd626e11f787f501beee2
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Mar 13 17:20:09 2023 +0100

    [gdb/testsuite] Require ![is_remote host] for TUI
    
    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.

Diff:
---
 gdb/testsuite/lib/tuiterm.exp | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gdb/testsuite/lib/tuiterm.exp b/gdb/testsuite/lib/tuiterm.exp
index 8a3f7a48acc..05edfe9a5b1 100644
--- a/gdb/testsuite/lib/tuiterm.exp
+++ b/gdb/testsuite/lib/tuiterm.exp
@@ -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
 	}