On Sat, 2014-02-15 at 10:01 +0000, Richard Sandiford wrote:
> Maybe a safer fix would be to provide sim_file instead. Untested patch below.
>
> Of course, that leaves remote_exec broken, but if it gets called and fails
> in other contexts then maybe it'd be clearer then whether to use host
> execution or to split out most of sim_load into sim_exec.
>
> Thanks,
> Richard
I tested your sim_file and it worked fine for me. Since we don't really
know what sim_exec should be doing maybe we should define one that
aborts. I am not sure if this is completely correct since sim_exec
never seems to get called when running the GCC testsuite (given that
sim_file exists) but here is what I tested. I am not sure if both the
perror and the verbose is needed in sim_exec.
Steve Ellcey
sell...@mips.com
2014-02-21 Steve Ellcey <sell...@mips.com>
Richard Sandiford <rdsandif...@googlemail.com>
* config/sim.exp (sim_exec): New.
(sim_file): New.
diff --git a/config/sim.exp b/config/sim.exp
index ab83835..87bd403 100644
--- a/config/sim.exp
+++ b/config/sim.exp
@@ -133,6 +133,16 @@ proc sim_upload { dest srcfile args } {
return [remote_upload host $srcfile $args]
}
+proc sim_exec { dest srcfile args } {
+ perror "Remote execution for simulators not implemented."
+ verbose -log "Remote execution for simulators not implemented."
+ return -1
+}
+
+proc sim_file { board args } {
+ return [eval [list remote_file host] $args]
+}
+
set_board_info protocol "sim"
# By default, assume the simulator is slow. This causes some tests
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
