From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20517 invoked by alias); 13 Feb 2014 23:10:06 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20504 invoked by uid 89); 13 Feb 2014 23:10:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2014 23:10:05 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1WE5Pr-0005o0-14 from joseph_myers@mentor.com ; Thu, 13 Feb 2014 15:09:59 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 15:09:59 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Thu, 13 Feb 2014 23:09:57 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1WE5Po-0006uB-5f; Thu, 13 Feb 2014 23:09:56 +0000 Date: Thu, 13 Feb 2014 23:10:00 -0000 From: "Joseph S. Myers" To: Steve Ellcey CC: Subject: Re: [PATCH, testsuite] Fix profile test failures In-Reply-To: <2e4e3d80-6505-4f09-8a24-01e99dcda418@BAMAIL02.ba.imgtec.org> Message-ID: References: <2e4e3d80-6505-4f09-8a24-01e99dcda418@BAMAIL02.ba.imgtec.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-02/txt/msg00865.txt.bz2 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). > 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. 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. -- Joseph S. Myers joseph@codesourcery.com