From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55717 invoked by alias); 13 Oct 2017 09:28:31 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 54726 invoked by uid 89); 13 Oct 2017 09:28:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:888 X-HELO: mailapp01.imgtec.com Received: from mailapp02.imgtec.com (HELO mailapp01.imgtec.com) (217.156.133.132) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Oct 2017 09:28:29 +0000 Received: from HHMAIL03.hh.imgtec.org (unknown [10.44.0.21]) by Forcepoint Email with ESMTPS id 4417DC5CE9D35; Fri, 13 Oct 2017 10:28:24 +0100 (IST) Received: from [10.20.78.202] (10.20.78.202) by HHMAIL03.hh.imgtec.org (10.44.0.21) with Microsoft SMTP Server id 14.3.361.1; Fri, 13 Oct 2017 10:28:26 +0100 Date: Fri, 13 Oct 2017 09:28:00 -0000 From: "Maciej W. Rozycki" To: Andreas Arnez CC: Pedro Alves , Kevin Buettner , Subject: Re: [PATCH 1/2] GDB test suite: Add helper for locating core files In-Reply-To: Message-ID: References: <1505760152-28775-1-git-send-email-arnez@linux.vnet.ibm.com> <1505760152-28775-2-git-send-email-arnez@linux.vnet.ibm.com> <20171007094545.1bba5c51@pinnacle.lan> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2017-10/txt/msg00343.txt.bz2 On Thu, 12 Oct 2017, Andreas Arnez wrote: > > This seems incorrect to me. "isnative" only checks > > if the build and target _triplets_ are the same. So > > foo-linux-gnu gdb x foo-linux-gnu gdbserver on separate > > machine still returns isnative==true. > > Exactly, that's why I originally wrote is_remote instead. And I also > wondered why the core dump tests check isnative. Does anyone run the > testsuite on a native remote setup? Well, I had cases where I did that, and offhand I can find two reasons: 1. You want to verify `gdbserver' itself rather than GDB, in which case you may even run it locally (i.e. where the remote target is really `localhost'). 2. You want to test a feature (e.g. an extra register set) only your target system has and it is too slow or unequipped to run DejaGNU itself. Maciej