Hi,
in our context of extensive GCC cross validation with parallel make
check and ssh/scp communication to the target boards, we have lot of
unstable results (mainly in fortran and libstdc++ testsuite) whereas
there is no issues in native testing. After lot of digging it occurs
that these instabilities are due to conflicting access to data or
generated temporary files.
The issue is that it is hardcoded in unix_load (and standard_load)
that the program to test is download under /tmp as "/tmp/progname.pid"
and executed in the homedir of the ssh user (or the one targeted by
board_info rsh_prog) and the data files needed by some testcases are
downloaded by remote_download which put them in the homedir as well.
So, all the data files and generated ones from the different processes
are in the same directory, thus the conflicts.
To fix this issue, changing the layout to have the testcases
downloaded and executed inside "/tmp/pid/" directory would do the job,
but as this change might have an impact on other project or on other
config which use remote_download, my proposal is to offer the
possibility to define the remote directory in which testcases will be
downloaded and executed with a target board info named "remote_dir".
A board spec with the line bellow will then fix our issue:
set_board_info remote_dir "/tmp/[pid]"
The attached patch implements this feature, it was tested on full GCC
testsuite without any issues, and if you think it's ok I can submit it
with an appropriate ChangeLog.
I would have prefer to have this issue fully fixed inside dejagnu, but
my fear is to brake something I can't test, so do you think it is the
proper way to handle the problem ?
If you think this solution is right, I have some comments and/or
related questions on the patch itself:
- I constraint the remote_dir handling to unix_load and the "remote_"
routines, it can easily be added to the standard_ ones (/tmp is also
hardcoded into standard_load) and/or in the various protocol routines
(rsh, ssh ...), I didn't do it as, from what I see in our toolchains'
testsuites, remote_ routines are the entry points, but do you think it
is something needed ?
- I didn't modified remote_upload routine to upload a file from the
given remote_dir as it will brake testcases like profiling feedback
ones which generate the profile info files in a specific directory, do
you think this behavior makes sense, or that GCC profiling harness
have to be changed to handle a dedicated remote dir ?
Thanks
Yvan
diff --git a/config/unix.exp b/config/unix.exp
index 5320ab7..4be5849 100644
--- a/config/unix.exp
+++ b/config/unix.exp
@@ -114,7 +114,12 @@ proc unix_load { dest prog args } {
set output [lindex $status 1]
set status [lindex $status 0]
} else {
- set remotefile "/tmp/[file tail $prog].[pid]"
+ # Target board remote_dir is handled by remote.exp routines.
+ if {[board_info $dest exists remote_dir]} {
+ set remotefile [file tail $prog]
+ } else {
+ set remotefile "/tmp/[file tail $prog].[pid]"
+ }
set remotefile [remote_download $dest $prog $remotefile]
if { $remotefile == "" } {
verbose -log "Download of $prog to [board_info $dest name] failed."
3
diff --git a/lib/remote.exp b/lib/remote.exp
index c334416..677cb9e 100644
--- a/lib/remote.exp
+++ b/lib/remote.exp
@@ -283,6 +283,8 @@ proc local_exec { commandline inp outp timeout } {
# redirected).
#
proc remote_exec { hostname program args } {
+ global remotedir
+
if { [llength $args] > 0 } {
set pargs [lindex $args 0]
} else {
@@ -314,6 +316,10 @@ proc remote_exec { hostname program args } {
if { ![is_remote $hostname] } {
return [local_exec "$program $pargs" $inp $outp $timeout]
} else {
+ if { [info exists remotedir] } {
+ set program "cd $remotedir ; $program"
+ }
+
return [call_remote "" exec $hostname $program $pargs $inp $outp]
}
}
@@ -420,6 +426,8 @@ proc standard_reboot { host } {
#
proc remote_download { dest file args } {
+ global remotedir
+
if { [llength $args] > 0 } {
set destfile [lindex $args 0]
} else {
@@ -447,6 +455,18 @@ proc remote_download { dest file args } {
}
}
}
+ if { [board_info $dest exists remote_dir] } {
+ if { ![info exists remotedir] } {
+ set rtmp [board_info $dest remote_dir]
+ set status [remote_exec $dest mkdir "-p $rtmp"]
+ if { [lindex $status 0] != 0 } {
+ verbose -log "Couldn't create remote directory $rtmp on $dest" 3
+ return [list "unresolved" ""]
+ }
+ set remotedir $rtmp
+ }
+ set destfile "$remotedir/$destfile"
+ }
return [call_remote "" download $dest $file $destfile]
}
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
