[pushed 0/3] [gdb/testsuite] Various fixes for gdb.server/multi-ui-errors.exp

[pushed 0/3] [gdb/testsuite] Various fixes for gdb.server/multi-ui-errors.exp

[Tom de Vries]

I ran test-case gdb.server/multi-ui-errors.exp with a few host/target boards
from gdb/testsuite/boards and fixed a few problems in the test-case and some
target boards.

Because the last patch changes target boards remote-gdbserver-on-localhost.exp
and remote-stdio-gdbserver.exp, I did a full test run with both of them.

Progressions (so, complete pass or less or later failures) in either or both
boards in test-cases:
- gdb.base/interrupt.exp
  (remote-stdio-gdbserver only)
- gdb.server/multi-ui-errors.exp
- gdb.server/server-kill-python.exp
- gdb.server/server-kill.exp
- gdb.arch/amd64-stap-special-operands.exp
  (remote-gdbserver-on-localhost only)

I ran into one regression, which I filed as
https://sourceware.org/bugzilla/show_bug.cgi?id=29731 and decided it's a
duplicate of PR18717, so unrelated to the series.

Tested on x86_64-linux.

Tom de Vries (3):
  [gdb/testsuite] Consume output asap in gdb.server/multi-ui-errors.exp
  [gdb/testsuite] Fix gdb.server/multi-ui-errors.exp with
    local-remote-host-notty
  [gdb/testsuite] Use ssh -t in remote-*.exp

 .../boards/remote-gdbserver-on-localhost.exp     | 12 ++++++++++++
 gdb/testsuite/boards/remote-stdio-gdbserver.exp  | 12 ++++++++++++
 gdb/testsuite/gdb.server/multi-ui-errors.exp     | 16 +++++++++++++++-
 3 files changed, 39 insertions(+), 1 deletion(-)


base-commit: 488ed354c8514ba93286f8676a64b7841bb1fda4
-- 
2.35.3

[pushed 1/3] [gdb/testsuite] Consume output asap in gdb.server/multi-ui-errors.exp

[Tom de Vries]

With test-case gdb.server/multi-ui-errors.exp we see:
...
(gdb) PASS: multi-ui-errors.exp: main UI, prompt after gdbserver dies
continue^M
Continuing.^M
echo^M
(gdb) PASS: multi-ui-errors.exp: extra UI, prompt after gdbserver dies
...

The continue is issued earlier in the test-case, but the output has not been
consumed, which makes it show up much later.

Consume the continue output asap, to make it clear when the continue is issued:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver
continue^M
Continuing.^M
PASS: gdb.server/multi-ui-errors.exp: continue - extra UI
...

Tested on x86_64-linux.
---
 gdb/testsuite/gdb.server/multi-ui-errors.exp | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.server/multi-ui-errors.exp b/gdb/testsuite/gdb.server/multi-ui-errors.exp
index d3ddd0f2d08..8a1276fb272 100644
--- a/gdb/testsuite/gdb.server/multi-ui-errors.exp
+++ b/gdb/testsuite/gdb.server/multi-ui-errors.exp
@@ -75,7 +75,13 @@ with_spawn_id $extra_spawn_id {
 with_spawn_id $extra_spawn_id {
     gdb_test "target $gdbserver_protocol $gdbserver_gdbport" ".*" \
 	"connect to gdbserver"
-    send_gdb "continue\n"
+
+    # Issue a continue and consume the response.  Don't expect a prompt.
+    gdb_test_multiple "continue" "continue - extra UI" {
+	-re  "\r\nContinuing\.\r\n" {
+	    pass $gdb_test_name
+	}
+    }
 }
 
 # We're going to kill the gdbserver, but before we do, lets make sure
-- 
2.35.3

[pushed 2/3] [gdb/testsuite] Fix gdb.server/multi-ui-errors.exp with local-remote-host-notty

[Tom de Vries]

With test-case gdb.server/multi-ui-errors.exp and host board
local-remote-host-notty, I run into:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 29666    (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 29666^M
echo^M
Remote connection closed^M
(gdb) (gdb) FAIL: gdb.server/multi-ui-errors.exp: \
  main UI, prompt after gdbserver dies (timeout)
...

In contrast, with local-remote-host (so, everything the same but editing off):
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 31245    (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 31245^M
Remote connection closed^M
(gdb) echo^M
(gdb) PASS: gdb.server/multi-ui-errors.exp: main UI, prompt after gdbserver dies
...

The test-case issues a kill, which results in a "Remote connection closed"
message and a prompt.

The problem is that the prompt is not consumed, so the subsequent echo may be
issued before that prompt, which causes a mismatch when matching the result
of the echo.

Fix this by consuming the "Remote connection closed" message and prompt.

Tested on x86_64-linux.
---
 gdb/testsuite/gdb.server/multi-ui-errors.exp | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gdb/testsuite/gdb.server/multi-ui-errors.exp b/gdb/testsuite/gdb.server/multi-ui-errors.exp
index 8a1276fb272..45a2dabbd6c 100644
--- a/gdb/testsuite/gdb.server/multi-ui-errors.exp
+++ b/gdb/testsuite/gdb.server/multi-ui-errors.exp
@@ -111,6 +111,14 @@ remote_exec target "kill -9 $gdbserver_pid"
 # The point is that we should be able to interact with GDB from either
 # interpreter now.
 
+with_spawn_id $gdb_main_spawn_id {
+    gdb_test_multiple "" "remote connection closed - main UI" {
+	-re -wrap "Remote connection closed" {
+	    pass $gdb_test_name
+	}
+    }
+}
+
 with_spawn_id $gdb_main_spawn_id {
     gdb_test "echo" "" \
 	"main UI, prompt after gdbserver dies"
-- 
2.35.3

[pushed 3/3] [gdb/testsuite] Use ssh -t in remote-*.exp

[Tom de Vries]

When running test-case gdb.server/multi-ui-errors.exp on target board
remote-gdbserver-on-localhost.exp, I run into:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver
continue^M
Continuing.^M
PASS: gdb.server/multi-ui-errors.exp: continue - extra UI
Remote debugging from host ::1, port 35466^M
FAIL: gdb.server/multi-ui-errors.exp: ensure inferior is running
...

The problem is that the target board uses ssh -T, which fails to guarantee
that output from the inferior will be available.

Fix this by copying proc ${board}_spawn from local-remote-host.exp, which
ensures using ssh -t.  [ It would be nice to define an ssh base board to
get rid of the copies, but I'm not addressing that in this commit. ]

Likewise for target board remote-stdio-gdbserver.exp.

Tested on x86_64-linux.
---
 .../boards/remote-gdbserver-on-localhost.exp         | 12 ++++++++++++
 gdb/testsuite/boards/remote-stdio-gdbserver.exp      | 12 ++++++++++++
 2 files changed, 24 insertions(+)

diff --git a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
index 27224d39d0b..dacbbfb6f28 100644
--- a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
+++ b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
@@ -32,6 +32,18 @@ set_board_info protocol standard
 set_board_info username $env(USER)
 set_board_info hostname localhost
 
+proc ${board}_spawn { board cmd } {
+    global board_info
+
+    set remote [board_info $board hostname]
+    set username [board_info $board username]
+    set RSH [board_info $board rsh_prog]
+
+    spawn $RSH -t -l $username $remote $cmd
+    set board_info($board,fileid) $spawn_id
+    return $spawn_id
+}
+
 # We will be using the standard GDB remote protocol
 set_board_info gdb_protocol "remote"
 
diff --git a/gdb/testsuite/boards/remote-stdio-gdbserver.exp b/gdb/testsuite/boards/remote-stdio-gdbserver.exp
index e1a2d0ed007..498526b7870 100644
--- a/gdb/testsuite/boards/remote-stdio-gdbserver.exp
+++ b/gdb/testsuite/boards/remote-stdio-gdbserver.exp
@@ -78,3 +78,15 @@ proc ${board}_file { dest op args } {
     }
     return [eval [list standard_file $dest $op] $args]
 }
+
+proc ${board}_spawn { board cmd } {
+    global board_info
+
+    set remote [board_info $board hostname]
+    set username [board_info $board username]
+    set RSH [board_info $board rsh_prog]
+
+    spawn $RSH -t -l $username $remote $cmd
+    set board_info($board,fileid) $spawn_id
+    return $spawn_id
+}
-- 
2.35.3