public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug testsuite/29736] New: [gdb/testsuite] Review of remote host/target boards in gdb/testsuite/boards
@ 2022-10-31 14:48 vries at gcc dot gnu.org
2022-11-03 21:10 ` [Bug testsuite/29736] " vries at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: vries at gcc dot gnu.org @ 2022-10-31 14:48 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug testsuite/29736] [gdb/testsuite] Review of remote host/target boards in gdb/testsuite/boards
2022-10-31 14:48 [Bug testsuite/29736] New: [gdb/testsuite] Review of remote host/target boards in gdb/testsuite/boards vries at gcc dot gnu.org
@ 2022-11-03 21:10 ` vries at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: vries at gcc dot gnu.org @ 2022-11-03 21:10 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-11-03 21:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-31 14:48 [Bug testsuite/29736] New: [gdb/testsuite] Review of remote host/target boards in gdb/testsuite/boards vries at gcc dot gnu.org
2022-11-03 21:10 ` [Bug testsuite/29736] " vries at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).