[gdb/testsuite] Fix gdb.base/signals-state-child.exp for remote-gdbserver-on-localhost
With test-case gdb.base/signals-state-child.exp on target board
remote-gdbserver-on-localhost I run into:
...
builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
$outputs/gdb.base/signals-state-child/signals-state-child-standalone^M
bash: $outputs/gdb.base/signals-state-child/signals-state-child-standalone: \
Permission denied^M
Connection to localhost closed.^M^M
FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
...
The problem is that we're trying to run an executable on the target board using
a host path.
After fixing this by downloading the exec to the target board, we run into:
...
builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
signals-state-child-standalone^M
bash: signals-state-child-standalone: command not found^M
Connection to localhost closed.^M^M
FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
...
Fix this by using an absolute path name for the exec on the target board.
The dejagnu proc standard_file does not support op == "absolute" for target
boards, so add an implementation in remote-gdbserver-on-localhost.exp.
Also:
- fix a PATH-in-test-name issue
- cleanup gdb.txt and standalone.txt on target board
Tested on x86_64-linux.
diff --git a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
index 160d09f..a08d2d1 100644
--- a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
+++ b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
@@ -55,6 +55,27 @@
chmod go-rx ."
}
+proc ${board}_file { dest op args } {
+ global board_info
+ set username [board_info $dest username]
+
+ if { $op == "absolute" } {
+ set file [lindex $args 0]
+
+ if { [file pathtype $file] == "relative" } {
+ # Make sure we get an absolute file name relative to home
+ # dir of $username, not $env(USER).
+ set pwd [regsub $::env(USER) $::env(HOME) $username]
+ set file [remote_file build join $pwd $file]
+ }
+
+ return [remote_file build $op $file]
+ }
+
+ # Fall back to standard_file.
+ return [standard_file $dest $op {*}$args]
+}
+
proc ${board}_spawn { board cmd } {
global board_info
diff --git a/gdb/testsuite/gdb.base/signals-state-child.exp b/gdb/testsuite/gdb.base/signals-state-child.exp
index 938c69aa..57de402 100644
--- a/gdb/testsuite/gdb.base/signals-state-child.exp
+++ b/gdb/testsuite/gdb.base/signals-state-child.exp
@@ -59,15 +59,33 @@
# Run the program directly, and dump its initial signal actions and
# mask in "standalone.txt".
+if { [is_remote target] } {
+ set target_binfile_standalone \
+ [gdb_remote_download target $binfile-standalone]
+
+ # Ensure that target_binfile_standalone is absolute, to work around
+ # current dir not being included in PATH.
+ set target_binfile_standalone \
+ [remote_file target absolute $target_binfile_standalone]
+ if { $target_binfile_standalone == "" } {
+ # Not supported by default, but supported in for instance
+ # remote-gdbserver-on-localhost.exp.
+ unsupported "require failed: remote_file target absolute"
+ return
+ }
+} else {
+ set target_binfile_standalone $binfile-standalone
+}
+
# Use remote_spawn instead of remote_exec, like how we spawn gdb.
# This is in order to take the same code code paths in dejagnu
# compared to when running the program through gdb. E.g., because
# local_exec uses -ignore SIGHUP, while remote_spawn does not, if we
# used remote_exec, the test program would start with SIGHUP ignored
# when run standalone, but not when run through gdb.
-set res [remote_spawn target "$binfile-standalone"]
+set res [remote_spawn target "$target_binfile_standalone"]
if { $res < 0 || $res == "" } {
- untested "spawning $binfile-standalone failed"
+ untested "spawning \$target_binfile_standalone failed"
return 1
}
@@ -103,3 +121,8 @@
gdb_test "shell diff -s $standalone_txt $gdb_txt" \
"Files .* are identical.*" \
$test
+
+if { [is_remote target] } {
+ remote_file target delete gdb.txt
+ remote_file target delete standalone.txt
+}
