On Thu, 2014-02-13 at 23:09 +0000, Joseph S. Myers wrote: > On Thu, 13 Feb 2014, Steve Ellcey wrote: > > > While testing the C++ profiling tests in g++.dg/bprob and using the > > qemu simulator we discovered that these tests were passing when we ran > > the testsuite with no extra options but that if we specified some options > > on the testsuite run then the tests would fail with this message in the > > c++.log file: > > > > rsh: Could not resolve hostname multi-sim/-EL: Name or service not known > > That means your board file is buggy. If rsh is not the right way to > access your target system, you need to implement the board file methods in > some way other than rsh (possibly some operations should be no-ops, or do > something directly on the build system, if you have a shared filesystem).
I thought the bug was that it was using 'multi-sim/-EL' instead of just 'multi-sim'. I.e. I thought that target was a combination of where the test was run and what options were used, whereas host was just going to be where the test was run. I guess I was wrong about that. > > So while it seems weird that 'host' is the proper replacement for 'target' > > as the machine where the executable is run, this seems to be the right fix > > It's certainly not the proper replacement. If a file is on the target, > use target for deletion / manipulation; if it's on the host, use host for > deletion / manipulation; on build, use build; in multiple places, run the > deletion operation once per system with the file; to copy from target to > the system (build) running DejaGnu, use remote_upload specifying target; > to copy from host to build, use remote_upload specifying host; to copy > from build to host or target, use remote_download specifying host or > target as appropriate. So let me make sure I understand this: host is where you run the testsuite from, build is where the compilation happens (probably the same as host for most people), and target is where the test program is executed. > To determine whether anything should be changed in a GCC .exp file, reason > about which of the three systems (build, host, target) a file is on, or is > needed on, at each point, rather than looking at what does or does not > work with a buggy board file. I am not convinced that the problem is in the board file because the only tests I see fail this way are the ones in g++.exp/bprob and that is also the only GCC .exp file that uses remote_upload or remote_file with 'target'. I will dig into it some more and also try it with some different boards. Steve Ellcey sell...@mips.com
