From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3235A385380D; Mon, 31 Oct 2022 14:48:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3235A385380D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667227713; bh=b2EEHDnFrTGU0tyjfaKL69k1/XFPsZnDL4KhcXLqbHY=; h=From:To:Subject:Date:From; b=OMe2Vlxl91pIAzQF0FbVldQa09LC4Nzdkc0iONFB2yTvOnpTxSRt3NS7//QtGnCE0 y9a1eVZ6ONIDqprUdUYMf1mIVcE7SCEve8ItNnxpNHILibw+WA6xAMvkui6s5nkEGh GP2qEPxvfV82CGjHuYegj5i72PfDIn7ODcBYHIEs= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug testsuite/29736] New: [gdb/testsuite] Review of remote host/target boards in gdb/testsuite/boards Date: Mon, 31 Oct 2022 14:48:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: testsuite X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29736 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, specifical= ly 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. Bui= ld 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 ho= st 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 =3D=3D host =3D=3D target =3D=3D localhost So let's start, for contrast, with the usual configuration, which you get w= hen running the testsuite without specifying --host_board or --target_board (so build =3D=3D host =3D=3D target =3D=3D 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 =3D=3D host =3D=3D target =3D=3D 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 =3D=3D host =3D=3D target =3D=3D localhost, but modify the way tests = are run: execs that are normally launched using gdb, are here launched by gdbserver. IV. build =3D=3D host =3D=3D localhost, target =3D=3D remote There are two target boards, remote-gdbserver-on-localhost.exp and remote-stdio-gdbserver.exp that test on a remote target, accessing the remo= te 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 =3D=3D target =3D=3D localhost, host =3D=3D 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 h= ost 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 somew= hat 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 =3D=3D localhost, host =3D=3D target =3D=3D 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 t= hat we don't need the forced gdbserver setup. VII. build =3D=3D localhost, host =3D=3D remote, target =3D=3D remote, host= !=3D 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.=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 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 h= ave 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 arg= s } { gdb/testsuite/boards/local-remote-host.exp:proc ${board}_download { board s= rc 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 attrib= utes -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-targ= et, 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). --=20 You are receiving this mail because: You are on the CC list for the bug.=