Another board file for remote host
Commit Message
In the recent review to my patch about copying files to remote host,
we find that we need a board file which is more closely mapped real
remote host testing to improve coverage. With the board file
local-remote-host-native.exp, DejaGNU copies files to /tmp/gdb/ to
emulate the effect of remote host. Is it OK?
gdb/testsuite:
2014-08-28 Yao Qi <yao@codesourcery.com>
* boards/local-remote-host-native.exp: New file.
---
gdb/testsuite/boards/local-remote-host-native.exp | 79 +++++++++++++++++++++++
1 file changed, 79 insertions(+)
create mode 100644 gdb/testsuite/boards/local-remote-host-native.exp
Comments
On 08/28/2014 02:31 PM, Yao Qi wrote:
> In the recent review to my patch about copying files to remote host,
> we find that we need a board file which is more closely mapped real
> remote host testing to improve coverage. With the board file
> local-remote-host-native.exp, DejaGNU copies files to /tmp/gdb/ to
> emulate the effect of remote host. Is it OK?
>
> gdb/testsuite:
>
> 2014-08-28 Yao Qi <yao@codesourcery.com>
>
> * boards/local-remote-host-native.exp: New file.
> ---
> gdb/testsuite/boards/local-remote-host-native.exp | 79 +++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
> create mode 100644 gdb/testsuite/boards/local-remote-host-native.exp
>
> diff --git a/gdb/testsuite/boards/local-remote-host-native.exp b/gdb/testsuite/boards/local-remote-host-native.exp
> new file mode 100644
> index 0000000..a3fd2dc
> --- /dev/null
> +++ b/gdb/testsuite/boards/local-remote-host-native.exp
I'm confused on the choice of "native" for name.
local-remote-host.exp/local-remote-host-notty.exp seem just or more
more native to me, as they assume a shared filesystem, while
the whole point of this one is emulate the case of _not_ sharing
the filesystem?
> +# To use this file:
> +# bash$ cd ${build_dir}/gdb
> +# bash$ make check RUNTESTFLAGS="--host_board=local-remote-host-native --target_board=local-remote-host-native"
> +
> +if { $board_type == "target" } {
> + set_board_info compiler gcc
Why do we need to also use the board as a target board?
> +}
> +if { $board_type == "host" } {
> + set_board_info gdb_opts "-ex \"dir ${tmp_dir}\""
No biggie, but this:
set_board_info gdb_opts "-d \"${tmp_dir}\""
looks a little simpler to me, just for the fact that it runs
through less code / fewer indirections in GDB.
> +}
On Thu, 28 Aug 2014 15:31:30 +0200, Yao Qi wrote:
> With the board file
> local-remote-host-native.exp, DejaGNU copies files to /tmp/gdb/ to
> emulate the effect of remote host. Is it OK?
Could it use some more unique directory name so that parallel runs of
testsuites from multiple independent GDB directories work?
And also:
cd gdb; make -j20 -k check//unix/-m64 check//unix/-m32
etc.
IIUC instead of [file tail $src] it may be better to use $src's absolute
directory.
Sorry I did not test this patch if I miss anything.
Thanks,
Jan
Pedro Alves <palves@redhat.com> writes:
> I'm confused on the choice of "native" for name.
> local-remote-host.exp/local-remote-host-notty.exp seem just or more
> more native to me, as they assume a shared filesystem, while
> the whole point of this one is emulate the case of _not_ sharing
> the filesystem?
This board file is used to emulate the real remote host testing, in
which file system of host and build are not shared. To be concrete,
I'd like this board file to emulate the testing we do for native
mingw32 GDB. GDB is built on x86_64-linux, is run on Windows, and
does debugging on Windows. I find such testing mode exposes some
problems in test cases, such as files not copied to host or referencing
build file path on host, etc.
Existing board files local-remote-host-*.exp share the file system, so
the problem of copying needed files to host is not exposed.
This board file is to emulate the testing to a native gdb (host ==
target) on a remote host (host != build), so I name it
local-remote-host-native. At first, I name it local-remote-host-target,
but I discard it as it is confusing.
>
>> +# To use this file:
>> +# bash$ cd ${build_dir}/gdb
>> +# bash$ make check
>> RUNTESTFLAGS="--host_board=local-remote-host-native
>> --target_board=local-remote-host-native"
>> +
>> +if { $board_type == "target" } {
>> + set_board_info compiler gcc
>
> Why do we need to also use the board as a target board?
>
Because [is_remote target] is true when I pass
--host_board=local-remote-host-native
--target_board=local-remote-host-native to DejaGNU. If I do
"--host_board=local-remote-host-native (--target_board=unix)",
[is_remote target] is false. Since I am doing test under target == host
!= build, so [is_remote target] is expected to be true, isn't?
>> +}
>
>> +if { $board_type == "host" } {
>> + set_board_info gdb_opts "-ex \"dir ${tmp_dir}\""
>
> No biggie, but this:
>
> set_board_info gdb_opts "-d \"${tmp_dir}\""
>
> looks a little simpler to me, just for the fact that it runs
> through less code / fewer indirections in GDB.
OK, I'll fix it.
I realize that the rationale and explanations are missing for this board
file, and I'll add more comments about them if the board file is OK.
Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> Could it use some more unique directory name so that parallel runs of
> testsuites from multiple independent GDB directories work?
> And also:
> cd gdb; make -j20 -k check//unix/-m64 check//unix/-m32
> etc.
Do we want to run testing in remote host in parallel? If RUNTESTFLAGS
is not empty, the tests will be serialized unless FORCE_PARALLEL is set.
IIRC, when Tom worked on parallel testing, we think it should be fine to
leave remote host testing serialized.
>
> IIUC instead of [file tail $src] it may be better to use $src's absolute
> directory.
Do you mean, supposing $src is /home/yao/src/gdb/testsuite/gdb.base/foo.c,
copy it to /tmp/gdb/home/yao/src/gdb/testsuite/gdb.base/foo.c?
On Thu, Aug 28, 2014 at 6:31 AM, Yao Qi <yao@codesourcery.com> wrote:
> In the recent review to my patch about copying files to remote host,
> we find that we need a board file which is more closely mapped real
> remote host testing to improve coverage. With the board file
> local-remote-host-native.exp, DejaGNU copies files to /tmp/gdb/ to
> emulate the effect of remote host. Is it OK?
>
> gdb/testsuite:
>
> 2014-08-28 Yao Qi <yao@codesourcery.com>
>
> * boards/local-remote-host-native.exp: New file.
I haven't given this a try yet, which I want to do, but thanks for
taking this on!
On Fri, 29 Aug 2014 03:51:51 +0200, Yao Qi wrote:
> Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>
> > Could it use some more unique directory name so that parallel runs of
> > testsuites from multiple independent GDB directories work?
> > And also:
> > cd gdb; make -j20 -k check//unix/-m64 check//unix/-m32
> > etc.
>
> Do we want to run testing in remote host in parallel? If RUNTESTFLAGS
> is not empty, the tests will be serialized unless FORCE_PARALLEL is set.
This is unrelated as I can run multiple testsuites at once on the same host
from unrelated GDB source-trees/build/trees.
Besides that I do use FORCE_PARALLEL:
http://git.jankratochvil.net/?p=nethome.git;a=blob;f=bin/hammock
I even run all testsuites twice at the same time - for i686 and x86_64
although I run them in different chroots so this issue would not matter.
But I could run the i686 build even on x86_64 just compiling everything
with -m32 (which I also do).
> > IIUC instead of [file tail $src] it may be better to use $src's absolute
> > directory.
>
> Do you mean, supposing $src is /home/yao/src/gdb/testsuite/gdb.base/foo.c,
> copy it to /tmp/gdb/home/yao/src/gdb/testsuite/gdb.base/foo.c?
Yes. There may be other options (such as using something PID-based etc.) but
I find the absolute pathname probably the best one.
Thanks,
Jan
Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>> > cd gdb; make -j20 -k check//unix/-m64 check//unix/-m32
>> > etc.
>>
>> Do we want to run testing in remote host in parallel? If RUNTESTFLAGS
>> is not empty, the tests will be serialized unless FORCE_PARALLEL is set.
>
> This is unrelated as I can run multiple testsuites at once on the same host
> from unrelated GDB source-trees/build/trees.
>
> Besides that I do use FORCE_PARALLEL:
> http://git.jankratochvil.net/?p=nethome.git;a=blob;f=bin/hammock
Do you plan to use this board file local-remote-host-native.exp to run
tests in parallel (set FORCE_PARALLEL to 1)? If yes, I am not sure it
is correct, because I don't think current gdb testsuite support parallel
testing for remote host. If no, why do we have to worry about parallel
testing? We can mention that parallel testing with this board file is
not supported.
>
> I even run all testsuites twice at the same time - for i686 and x86_64
> although I run them in different chroots so this issue would not matter.
> But I could run the i686 build even on x86_64 just compiling everything
> with -m32 (which I also do).
If you think it is unsafe to copy files to a global place (/tmp/gdb/),
how about copy files to ${build_testsuite}/remote-host?
${build_testsuite} is the directory created by GDB having the
"testsuite." prefix. For example, if we do:
make -k check //unix/{-m32,-m64}
the ${build_testsuite} will be ${build_dir}/gdb/testsuite.unix.{-m32,-m64},
and source files are copied to
${build_dir}/gdb/testsuite.unix.{-m32,-m64}/remote-host. Is it good to you?
On Mon, 01 Sep 2014 10:10:32 +0200, Yao Qi wrote:
> Do you plan to use this board file local-remote-host-native.exp to run
> tests in parallel (set FORCE_PARALLEL to 1)?
I do not think I will myself but I guess someone should setup a nightly (or
even per-commit) regression testing even in this mode.
> If yes, I am not sure it is correct, because I don't think current gdb
> testsuite support parallel testing for remote host.
I have never been dealing with remote hosts testing so I do not know.
But I find it a bug in such case.
> If no, why do we have to worry about parallel testing?
I find it a bug that something does not work during parallel testing while it
could. Testsuite takes IIRC half an hour or more in non-parallel mode.
> We can mention that parallel testing with this board file is
> not supported.
In such case it should IMNSHO print an error so that people do not have to
chase random testsuite failures if they do so and they miss the documentation
mentioning it.
> If you think it is unsafe to copy files to a global place (/tmp/gdb/),
> how about copy files to ${build_testsuite}/remote-host?
I find that really the best. Although it still should use more than
a basename as there are duplicate basenames in the gdb.* directions:
for i in gdb/testsuite/gdb.*;do find $i -type f -printf "%f\n";done|sort|uniq -d
Thanks,
Jan
new file mode 100644
@@ -0,0 +1,79 @@
+# Copyright 2014 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# This file is a dejagnu "board file" and is used to run the testsuite
+# against local host, in remote host mode.
+#
+# To use this file:
+# bash$ cd ${build_dir}/gdb
+# bash$ make check RUNTESTFLAGS="--host_board=local-remote-host-native --target_board=local-remote-host-native"
+
+if { $board_type == "target" } {
+ set_board_info compiler gcc
+}
+
+global GDB
+set GDB [file join [pwd] "../gdb"]
+
+set_board_info hostname 127.0.0.1
+
+set_board_info username $env(USER)
+
+# The ssh key should be correctly set up that you ssh to 127.0.0.1
+# without having to type password.
+set_board_info rsh_prog /usr/bin/ssh
+set_board_info rcp_prog /usr/bin/scp
+set_board_info file_transfer "rsh"
+
+# The directory to copy files to. In default, we choose /tmp/gdb, to
+# avoiding messing up your HOME. You can choose other directory as
+# you like.
+set tmp_dir "/tmp/gdb"
+
+if { $board_type == "host" } {
+ set_board_info gdb_opts "-ex \"dir ${tmp_dir}\""
+}
+
+proc ${board}_spawn { board cmd } {
+ global board_info
+
+ set remote [board_info $board hostname]
+ set username [board_info $board username]
+ set RSH [board_info $board rsh_prog]
+
+ spawn $RSH -t -l $username $remote $cmd
+ set board_info($board,fileid) $spawn_id
+ return $spawn_id
+}
+
+proc ${board}_download { board src dest } {
+ global env board_type
+ global tmp_dir
+
+ if { [llength $dest] > 0 } {
+ set destfile [lindex $dest 0]
+ } else {
+ set destfile [file tail $src]
+ }
+
+ if { ![file exists $tmp_dir] } {
+ file mkdir $tmp_dir
+ }
+
+ set destfile [file join $tmp_dir $destfile]
+ file copy -force $src $destfile
+
+ return $destfile
+}