From patchwork Mon Nov 7 16:13:27 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 60119 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 52D9A385803E for ; Mon, 7 Nov 2022 16:14:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 52D9A385803E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667837649; bh=2CHP3Fri3bzLYCLhXMklhSdDhGJKmT057kf3EdvpbeU=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=J4xG/BVHpVgMwt7Mnnz9for3H2IGgBavSw1JO9Sd+X4ReQdO7llWe2rWvKNPutoiz T2lcS5rX3644Wc0ydYgqpEZcul14/G2lyFZ4CVYu4+h/q+ref53xESKhJU/UeNeMmt S/gh8b+Wl4MFy1Th4uu16SZR2DzvTzcrtBRI0rro= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id F1C433858D39 for ; Mon, 7 Nov 2022 16:13:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F1C433858D39 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 2EB4A22627 for ; Mon, 7 Nov 2022 16:13:34 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 1B27B13ADB for ; Mon, 7 Nov 2022 16:13:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 6O+LBa4uaWPsTwAAMHmgww (envelope-from ) for ; Mon, 07 Nov 2022 16:13:34 +0000 To: gdb-patches@sourceware.org Subject: [PATCH 3/9] [gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp Date: Mon, 7 Nov 2022 17:13:27 +0100 Message-Id: <20221107161333.16999-4-tdevries@suse.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20221107161333.16999-1-tdevries@suse.de> References: <20221107161333.16999-1-tdevries@suse.de> MIME-Version: 1.0 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Tom de Vries via Gdb-patches From: Tom de Vries Reply-To: Tom de Vries Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" As reported here ( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a number of test-cases fails with a remote target setup, for instance test-case gdb.base/print-file-var.exp. So, why don't we see these fails with our remote target boards in gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp? The problem is that the target board uses the same machine and user for both (by-definition-local) build and remote target, and when using absolute pathnames to refer to files on build, we can access those files on target, which in a real remote target setup wouldn't be the case: we'd have to download them to target first, and then the filename would also be different. For aforementioned test-case, this happens when the name of a shared library is passed as absolute file name to gcc: ... gcc ... -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\ print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so" ... Make these problems visible with remote-gdbserver-on-localhost.exp by adding an option to specify a test account (still on the same machine) using REMOTE_TARGET_USERNAME. We make sure by restricting file permissions, that the test account cannot see the build files on the $USER account, and that the $USER account cannot see the target files on the test account. And so we can reproduce the reported fails: ... $ cd build/gdb $ tc="gdb.base/print-file-var.exp" $ tb="--target_board remote-gdbserver-on-localhost" $ tbu="REMOTE_TARGET_USERNAME=remote-target" $ make check RUNTESTFLAGS="$tb $tbu $tc" ... FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \ version_id_main=0: continue to STOP marker ... Tested on x86_64-linux. Reported-by: Ivan Tetyushkin --- .../boards/remote-gdbserver-on-localhost.exp | 30 +++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp index dacbbfb6f28..f74b549f28f 100644 --- a/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp +++ b/gdb/testsuite/boards/remote-gdbserver-on-localhost.exp @@ -18,7 +18,8 @@ # # To use this file: # bash$ cd ${build_dir}/gdb -# bash$ make check RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost" +# bash$ make check RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost +# [ REMOTE_TARGET_USERNAME= ]" load_generic_config "gdbserver" load_board_description "gdbserver-base" @@ -29,9 +30,34 @@ load_board_description "gdbserver-base" set_board_info rcp_prog "/usr/bin/scp" set_board_info rsh_prog "/usr/bin/ssh" set_board_info protocol standard -set_board_info username $env(USER) +if { [info exists REMOTE_TARGET_USERNAME] } { + set_board_info username $REMOTE_TARGET_USERNAME +} else { + set_board_info username $env(USER) +} set_board_info hostname localhost +# Handle separate test account. +if { [board_info $board username] != $env(USER) } { + # We're pretending that some local user account is remote target. + # Make things a bit more realistic by restricting file permissions. + + # Make sure remote target can't see files on build. Note that we're + # currently using $objdir/output instead of $objdir because of gdbserver + # being accessed on the target using $objdir/../../gdbserver/gdbserver. + remote_exec build "chmod go-rx $objdir/outputs" + + # Make sure build can't see files on remote target. We can't use + # remote_exec target, because we're in the middle of parsing the + # target board. + remote_exec build \ + "[board_info $board rsh_prog] \ + -l [board_info $board username] \ + [board_info $board hostname] \ + chmod go-rx ." +} + + proc ${board}_spawn { board cmd } { global board_info