[gdb/testsuite] Fix gdb.base/signals-state-child.exp for remote-gdbserver-on-localhost
authorTom de Vries <tdevries@suse.de>
Tue, 7 Mar 2023 13:46:24 +0000 (14:46 +0100)
committerTom de Vries <tdevries@suse.de>
Tue, 7 Mar 2023 13:46:24 +0000 (14:46 +0100)
commit1b79c725e40e4258bdd9254e7a250c4b807d28b6
tree9b40211cab0bd466059f3cdac9babf2ec9a7c271
parenta50a8e305d4406d96adb5b2967236d7b8767997f
[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
gdb/testsuite/gdb.base/signals-state-child.exp