The remote-stdio-gdbserver.exp board should work, but be aware of this
issue that was reported recently:
https://sourceware.org/ml/gdb/2018-01/msg00023.html
I just tried it and stumbled on another bug, if you are using
gdb/gdbserver 8.1. You might get something like this in gdb.log:
(gdb) target remote | /usr/bin/ssh simark@s.thetu.bz
/usr/bin/gdbserver --once stdio jump
Remote debugging using | /usr/bin/ssh simark@s.thetu.bz
/usr/bin/gdbserver --once stdio jump
stdin/stdout redirected
zsh:1: command not found: jump
During startup program exited with code 127.
This is likely caused by the fact that gdbserver now starts (by
default) the inferior process through a shell. If you run "gdbserver
... jump", it will try to run the "jump" command through the shell,
which is not found because it's not in the path. I worked around it
by doing this simple change:
diff --git a/gdb/testsuite/boards/remote-stdio-gdbserver.exp
b/gdb/testsuite/boards/remote-stdio-gdbserver.exp
index aff7902..3e01d1b 100644
--- a/gdb/testsuite/boards/remote-stdio-gdbserver.exp
+++ b/gdb/testsuite/boards/remote-stdio-gdbserver.exp
@@ -70,7 +70,7 @@ proc get_remote_login { } {
proc get_target_remote_pipe_cmd { } {
set target_exec [gdbserver_download_current_prog]
set rsh_cmd "[board_info [target_info name] rsh_prog]
[get_remote_login]"
- return "$rsh_cmd /usr/bin/gdbserver --once stdio $target_exec"
+ return "$rsh_cmd /usr/bin/gdbserver --once stdio ./$target_exec"
}
proc ${board}_file { dest op args } {
With this I'm able to test using a remote gdbserver between two x86
machines (though note that it uses the gdbserver on the target
machine, the testsuite doesn't upload it itself).
Simon