[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.

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
 

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
+}