This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Testing with remote gdbserver
- From: Simon Marchi <simon dot marchi at polymtl dot ca>
- To: Dmitry Antipov <dantipov at nvidia dot com>
- Cc: GDB Development <gdb at sourceware dot org>
- Date: Thu, 08 Feb 2018 11:28:07 -0500
- Subject: Re: Testing with remote gdbserver
- Authentication-results: sourceware.org; auth=none
- References: <1eca7308-60e6-5c39-1eae-1f9dc1c034f1@nvidia.com>
On 2018-02-08 09:29, Dmitry Antipov wrote:
Hello,
are there any known-to-work board configuration files to test
gdbserver remotely?
After reading https://sourceware.org/gdb/wiki/TestingGDB, I supposed
that this
has to be relatively simple, at least between two GNU/Linux x86
machines with public
key-based ssh access between them. But, since I just have a) noise
about missing 'runtest'
(which is /usr/bin/runtest in my $PATH), b) a lot of FAILED messages
(probably due to
communication timeouts) and c) time-to-time zombie ssh processes, I
assume that my setup
is grossly misconfigured at some non-obvious but very important point.
I've started
from example remote board file taken from "Testing gdbserver in a
remote cross-target
configuration" of the above and tried some tweaks, but still have no
PASSes (except
for local libiberty tests). Is it possible to run the tests in a "much
more verbose"
mode to check what's going on?
Thanks in advance,
Dmitry
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