From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [committed][gdb/testsuite] Fix spawn in tuiterm.exp
Date: Thu, 27 Feb 2020 09:17:00 -0000 [thread overview]
Message-ID: <20200227091737.GA21524@delia> (raw)
Hi,
When running gdb.stabs/weird.exp by itself it passes, but if we run a gdb.tui
test before it, we get:
...
$ make check RUNTESTFLAGS="gdb.stabs/weird.exp gdb.tui/basic.exp"
Running /data/gdb_versions/devel/src/gdb/testsuite/gdb.tui/basic.exp ...
Running /data/gdb_versions/devel/src/gdb/testsuite/gdb.stabs/weird.exp ...
ERROR: Couldn't make test case. -1 {spawn failed}
...
In more detail, using -v:
...
Executing on build: sed -f aout.sed weird.def weird.s (timeout = 300)
builtin_spawn [open ...]^M
pid is 19060 19061 -19060 -19061
spawn -open file10 failed, 1 can't read "spawn_out(slave,name)": \
no such variable, can't read "spawn_out(slave,name)": no such variable
while executing
"set gdb_spawn_name $spawn_out(slave,name)"
(procedure "spawn" line 5)
invoked from within
"spawn -ignore SIGHUP -leaveopen file10"
invoked from within
"catch "spawn -ignore SIGHUP -leaveopen $id" result2"
ERROR: Couldn't make test case. -1 {spawn failed}
...
When running the gdb.tui test, spawn gets renamed to a local version from
lib/tuiterm.exp. The local version calls expect's spawn, and then makes the
local spawn_out(slave,name) variable accessible in the global variable
gdb_spawn_name.
However, the weird.exp test-case uses remote_exec build, which ends up using
local_exec, which given that there's input/output redirection uses open:
...
set result [catch {open "| ${commandline} $inp |& tee $outpf" RDONLY} id]
...
followed by spawn using the -leaveopen option:
...
set result [catch "spawn -ignore SIGHUP -leaveopen $id" result2]
...
which apparently has the effect that spawn_out(slave,name) is not set.
Fix this in the lib/tuiterm.exp local spawn proc by detecting the case that
spawn_out(slave,name) is not set, and handling it accordingly.
Tested gdb.stabs/weird.exp and gdb.tui/*.exp on x86_64-linux.
Committed to trunk.
Thanks,
- Tom
[gdb/testsuite] Fix spawn in tuiterm.exp
gdb/testsuite/ChangeLog:
2020-02-27 Tom de Vries <tdevries@suse.de>
* lib/tuiterm.exp (spawn): Handle case that spawn_out(slave,name) is
not set.
---
gdb/testsuite/lib/tuiterm.exp | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gdb/testsuite/lib/tuiterm.exp b/gdb/testsuite/lib/tuiterm.exp
index da5580324a..7505821a85 100644
--- a/gdb/testsuite/lib/tuiterm.exp
+++ b/gdb/testsuite/lib/tuiterm.exp
@@ -24,7 +24,11 @@ proc spawn {args} {
set result [uplevel builtin_spawn $args]
global gdb_spawn_name
upvar spawn_out spawn_out
- set gdb_spawn_name $spawn_out(slave,name)
+ if { [info exists spawn_out] } {
+ set gdb_spawn_name $spawn_out(slave,name)
+ } else {
+ unset gdb_spawn_name
+ }
return $result
}
next reply other threads:[~2020-02-27 9:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 9:17 Tom de Vries [this message]
2020-02-27 16:49 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200227091737.GA21524@delia \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox