Testing with remote gdbserver

Testing with remote gdbserver

[Dmitry Antipov]

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

Re: Testing with remote gdbserver

[Yao Qi]

> (except
> for local libiberty tests). Is it possible to run the tests in a "much more
> verbose"
> mode to check what's going on?
>

$ make check RUNTESTFLAGS="-v --target_board=YOUR.BOARD YOUR_TEST.exp"

The more "-v" you put in RUNTESTFLAGS, the more verbose the output is.
IOW, you can do "-v -v -v" in RUNTESTFLAGS.

-- 
Yao (齐尧)

Re: Testing with remote gdbserver

[Simon Marchi]

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

Re: Testing with remote gdbserver

[Simon Marchi]

On 2018-02-08 11:28, Simon Marchi wrote:
> 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

For reference, here's the command line I used (replace example.com with 
the appropriate hostname/ip, of course):

make check TESTS="gdb.base/jump.exp" 
RUNTESTFLAGS="--target_board=remote-stdio-gdbserver 
REMOTE_USERNAME=simark REMOTE_HOSTNAME=example.com"

Simon