From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6937 invoked by alias); 20 Nov 2013 20:01:43 -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 6888 invoked by uid 89); 20 Nov 2013 20:01:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_50,RDNS_NONE autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Nov 2013 20:01:41 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VjDxl-0000QI-GH from Maciej_Rozycki@mentor.com ; Wed, 20 Nov 2013 12:01:25 -0800 Received: from SVR-IES-FEM-03.mgc.mentorg.com ([137.202.0.108]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Nov 2013 12:01:25 -0800 Received: from [172.30.64.178] (137.202.0.76) by SVR-IES-FEM-03.mgc.mentorg.com (137.202.0.108) with Microsoft SMTP Server id 14.2.247.3; Wed, 20 Nov 2013 20:01:23 +0000 Date: Wed, 20 Nov 2013 21:21:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: , Stan Shebs Subject: Re: [PATCH] gdb.mi/mi-info-os.exp: Fix cross-debugger testing In-Reply-To: <528D0AE0.50702@redhat.com> Message-ID: References: <528D0AE0.50702@redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-11/txt/msg00609.txt.bz2 On Wed, 20 Nov 2013, Pedro Alves wrote: > > Index: gdb-fsf-trunk-quilt/gdb/testsuite/gdb.mi/mi-info-os.exp > > =================================================================== > > --- gdb-fsf-trunk-quilt.orig/gdb/testsuite/gdb.mi/mi-info-os.exp 2013-11-01 00:52:48.000000000 +0000 > > +++ gdb-fsf-trunk-quilt/gdb/testsuite/gdb.mi/mi-info-os.exp 2013-11-01 00:56:43.588756235 +0000 > > @@ -33,6 +33,20 @@ if [mi_gdb_start] { > > continue > > } > > > > +# In non-native configurations we need to have a live target. > > +if { ![isnative] } { > > Shouldn't this be [is_remote target] ? isnative just compares > the _build_ and target triplets. Well is_remote merely checks if the target board is not the same as the local (build) machine. I don't think it matters, it doesn't tell anything about GDB configuration, e.g. GDB might be native after all, running on a remote host that is the same as the target (i.e. no `gdbserver' or suchlike involved, although we don't actually care here whether `gdbserver' is used or not), like in a crossed build of a native toolchain. FWIW I actually scanned our testsuite for various configuration conditions used before making this change and I believe the cases of [is_remote target] I saw are incorrect -- the authors of the pieces of code in question appear to have assumed that this condition translates to the use of the RSP and `gdbserver' while it is not what DejaGNU implements. All it implies is what I noted above -- that is that the target machine is not the same as the build machine (one running `make check' or the equivalent). That has nothing to do with `gdbserver' or the use of the RSP. > (And even if host and target triplets matched, we could still > have a configuration without a native target) How come? > Otherwise OK. So what is your proposal? What's the proper way of determining whether this configuration of GDB is native (includes a native target) or not? To maintain current coverage we need to complement the check made in target_get_osdata: if (current_target.to_stratum >= process_stratum) t = current_target.beneath; else t = find_default_run_target ("get OS data"); and do not connect to any target in configurations where find_default_run_target returns success. Maciej