From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31110 invoked by alias); 24 Jul 2004 23:59:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31103 invoked from network); 24 Jul 2004 23:59:46 -0000 Received: from unknown (HELO mclean.mail.mindspring.net) (207.69.200.57) by sourceware.org with SMTP; 24 Jul 2004 23:59:46 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BoWQW-0003ew-00; Sat, 24 Jul 2004 19:59:40 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 512244B102; Sat, 24 Jul 2004 19:59:11 -0400 (EDT) Date: Sat, 24 Jul 2004 23:59:00 -0000 From: Michael Chastain To: drow@false.org Subject: Re: [rfc/testsuite] editor.exp: new test script for "edit" command Cc: gdb-patches@sources.redhat.com Message-ID: <4102F7CD.nail50H11BZER@mindspring.com> References: <20040723064726.104F74B104@berman.michael-chastain.com> <20040723144524.GA10859@nevyn.them.org> In-Reply-To: <20040723144524.GA10859@nevyn.them.org> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00353.txt.bz2 Daniel Jacobowitz writes: > - GDB's testsuite assumes that host and build are the same. > So I don't know if the consistency is worth it unless someone > cares about separating them. I looked into this. Let me sort my thoughts. build == machine where dejagnu is running. host == machine where gdb and gcc is running. target == machine where test program (test.exe) is running Dejagnu supports separate build and host machines In default_target_compile, if host is remote from build, then default_target_compile calls remote_download to copy the test program source code (test.c) from build to host. default_target_compile also calls remote_upload to copy a.out back from host to build. If the test.c includes test.h, then test.exp has to download this file onto the host by hand. gdb.base/list.exp actually does this: remote_download host ${srcdir}/${subdir}/list0.h list0.h ... remote_exec build "rm -f list0.h" However, all these test scripts neglect to download their *.h files: gdb.arch/i386-sse.exp gdb.base/lineinc.exp gdb.base/macscp.exp gdb.base/overlays.exp gdb.base/shlib-call.exp gdb.cp/m-static.exp gdb.cp/rtti.exp gdb.hp/gdb.compat/xdb2.exp gdb.hp/gdb.objdbg/objdbg01.exp gdb.hp/gdb.objdbg/objdbg04.exp gdb.stabs/exclfwd.exp There are other issues with separate build and host, like core files. gdb creates them on the host machine, but then gcore.exp expects to see them on the build machine. I don't think there's much of a demand for the gdb testsuite to support separate build and host machines. So I'm going to propose a policy change, in the form of a documentation patch to the 'Testsuite' section of gdbint.texinfo, that the gdb test suite does not support separate build and host machines. (Of course we support separate host/build and target machines!) Michael C