public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [pushed] [gdb/testsuite] Fix gdb.base/signals-state-child.exp for remote-gdbserver-on-localhost
@ 2023-03-07 13:46 Tom de Vries
  0 siblings, 0 replies; only message in thread
From: Tom de Vries @ 2023-03-07 13:46 UTC (permalink / raw)
  To: gdb-patches

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.
---
 .../boards/remote-gdbserver-on-localhost.exp  | 21 +++++++++++++++
 .../gdb.base/signals-state-child.exp          | 27 +++++++++++++++++--
 2 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
index 160d09fc0e1..a08d2d19801 100644
--- a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
+++ b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp
@@ -55,6 +55,27 @@ if { [board_info $board username] != $env(USER) } {
 	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 938c69aa5a8..57de402a68b 100644
--- a/gdb/testsuite/gdb.base/signals-state-child.exp
+++ b/gdb/testsuite/gdb.base/signals-state-child.exp
@@ -59,15 +59,33 @@ if {[build_executable $testfile.exp $testfile-standalone $srcfile $options]} {
 # 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 @@ if {!$purely_local} {
 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
+}

base-commit: a50a8e305d4406d96adb5b2967236d7b8767997f
-- 
2.35.3


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-03-07 13:46 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-07 13:46 [pushed] [gdb/testsuite] Fix gdb.base/signals-state-child.exp for remote-gdbserver-on-localhost Tom de Vries

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).