[Bug testsuite/29736] New: [gdb/testsuite] Review of remote host/target boards in gdb/testsuite/boards

[Bug testsuite/29736] New: [gdb/testsuite] Review of remote host/target boards in gdb/testsuite/boards

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29736

            Bug ID: 29736
           Summary: [gdb/testsuite] Review of  remote host/target boards
                    in gdb/testsuite/boards
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I've been looking at the various boards in gdb/testsuite/boards, specifically
the boards that play around with local/remote host/target, fixing test-cases
here and there in an attempt to build up some understanding.


I. Background

Let's start with some background.

Dejagnu knows 3 types of machine roles:
- build (build host, or build machine)
- host (host board)
- target (target board)

Host and target can be either local (same machine as build) or remote.  Build
is local by definition.

In the context of the gdb testsuite, we have:
- build: runs dejagnu, contains $srcdir
- host: runs compiler, gdb
- target: runs gdbserver, exec

[ Each machine has a target triplet.  Dejagnu calls it native testing if host
and target have the same target triplet.  All the boards in
gdb/testsuite/boards are setup for native testing (well, apart from
simavr.exp), so target triplets are not discussed further here. ]


II. build == host == target == localhost

So let's start, for contrast, with the usual configuration, which you get when
running the testsuite without specifying --host_board or --target_board (so
build == host == target == localhost).

There are three types of test-cases:
- gdbserver launches exec (gdb.server/*.exp and a few others)
- gdb launches exec (most other test-cases)
- both gdb and gdbserver launch execs (some in gdb.multi/*.exp)


III. build == host == target == localhost, force gdbserver

There are a couple of target boards, native-gdbserver.exp,
native-extended-gdbserver.exp and native-stdio-gdbserver.exp that also have
build == host == target == localhost, but modify the way tests are run: execs
that are normally launched using gdb, are here launched by gdbserver.


IV. build == host == localhost, target == remote

There are two target boards, remote-gdbserver-on-localhost.exp and
remote-stdio-gdbserver.exp that test on a remote target, accessing the remote
target using ssh.  Note that the remote target also happens to be localhost,
but as far as dejagnu is considered it is a distinct machine.

Also here we force execs to be launched using gdbserver, because the target is
remote, and if gdb is launching an exec, it's running on the host, not the
target.


V. build == target == localhost, host == remote

There are two host boards, local-remote-host-notty.exp and
local-remote-host.exp that test using a remote host, accessing the remote host
using ssh.  Again, note that the remote host also happens to be localhost, but
as far as dejagnu is considered it is a distinct machine.

Here we don't force execs to be launched using gdbserver, which looks somewhat
strange, because also here if gdb is launching an exec, it's running on the
host, not the target.  We can get away with this because under the hood the
remote host and the local target are the same machine, but AFAIU, we're not
testing what we're supposed to test.

VI. build == localhost, host == target == remote

There is one host+target board, local-remote-host-native.exp where both host
and target are remote, but also the same machine.  The benefit of this is that
we don't need the forced gdbserver setup.

VII. build == localhost, host == remote, target == remote, host != target

This seems to be missing, but it seems a good idea to get the V case to work
properly first.

VIII. File handling

There are various attempts in the boards files to be smart about files, for
instance to:
- avoid copying files, or to
- avoid copying files into home dirs, which may run into conflicts with
  files and directories already in the home dir.

I wonder if this may go to the point of hiding problem in test-cases which then
will only show up with real remote testing.

In remote-stdio-gdbserver.exp we have:
...
 # Some remote machines don't have writable home directories.                   
if [info exists REMOTE_TMPDIR] {
    set_board_info remotedir $REMOTE_TMPDIR
}
...
I haven't tested this, but the remotedir is at least a dejagnu thingy.  I have
tried to make this work for remote host, but didn't manage so far.

Then we have various overrides for _file and _download:
...
$ egrep "proc .*\\\${board}_(file|download)" gdb/testsuite/boards/*.exp
gdb/testsuite/boards/local-remote-host.exp:proc ${board}_file { dest op args }
{
gdb/testsuite/boards/local-remote-host.exp:proc ${board}_download { board src
dest } {
gdb/testsuite/boards/local-remote-host-native.exp:proc ${board}_download {
board src dest } {
gdb/testsuite/boards/remote-stdio-gdbserver.exp:proc ${board}_file { dest op
args } {
...
It's hard to decide for me if these solutions are complete.

ISTM that:
- we're missing a gdb.testsuite/board-sanity.exp test-case that understands
  local and remote host and target and exercises various file operations
  such that we can tell whether a board has sane and consistent
  remote_upload/remote_download/remote_file definitions.
- it needs to be sorted out how board-specific file handling procs play
  along with remote_exec which also sometimes deals with files, so for
  instance should we avoid remote_exec chmod in favor of remote_file attributes
  -permissions for that reason.  Or intercept remote_exec as well to
  fiddle with file arguments?
- we'll need modes in these boards to use actual remote machines, which
  we can still use in localhost mode by specifying in .ssh/config a host
  remote-host-target with hostname 127.0.01 and a username remote-host-target,
  which brings us much closer to actual remote testing, and also solves
  the problem of conflicts with files/dirs in the homedir (because we
  can assume that these test accounts are empty).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/29736] [gdb/testsuite] Review of remote host/target boards in gdb/testsuite/boards

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29736

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> V. build == target == localhost, host == remote
> 
> There are two host boards, local-remote-host-notty.exp and
> local-remote-host.exp that test using a remote host, accessing the remote
> host using ssh.  Again, note that the remote host also happens to be
> localhost, but as far as dejagnu is considered it is a distinct machine.
> 
> Here we don't force execs to be launched using gdbserver, which looks
> somewhat strange, because also here if gdb is launching an exec, it's
> running on the host, not the target.  We can get away with this because
> under the hood the remote host and the local target are the same machine,
> but AFAIU, we're not testing what we're supposed to test.
> 

I've come to the conclusion that these host boards only make sense in
combination with one of the target boards that force gdbserver.

-- 
You are receiving this mail because:
You are on the CC list for the bug.