[gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp
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 <ivan.tetyushkin@syntacore.com>
This commit is contained in:
parent
9af7a37003
commit
2a1742f31c
@ -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=<remote_target_username> ]"
|
||||
|
||||
load_generic_config "gdbserver"
|
||||
load_board_description "gdbserver-base"
|
||||
@ -29,9 +30,33 @@ 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
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user