From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20246 invoked by alias); 15 Dec 2014 11:59:11 -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 20233 invoked by uid 89); 15 Dec 2014 11:59:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE 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; Mon, 15 Dec 2014 11:59:08 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1Y0UIr-0002pH-De from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Mon, 15 Dec 2014 03:59:05 -0800 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.181.6; Mon, 15 Dec 2014 03:59:04 -0800 From: Yao Qi To: "Breazeal, Don" CC: "Breazeal, Don" , "gdb-patches@sourceware.org" Subject: Re: [PATCH] Skipping tests that use remote protocol References: <1418344896-9036-1-git-send-email-donb@codesourcery.com> <877fxxzhmx.fsf@codesourcery.com> <548B3B3B.5060709@codesourcery.com> Date: Mon, 15 Dec 2014 11:59:00 -0000 In-Reply-To: <548B3B3B.5060709@codesourcery.com> (Don Breazeal's message of "Fri, 12 Dec 2014 11:00:11 -0800") Message-ID: <87mw6pt98q.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00374.txt.bz2 "Breazeal, Don" writes: > Hm. This would work for my attach example, but I don't think that this > check is sufficient for all cases (e.g. gdb.base/catch-syscall.exp, > which we want to skip for both "remote" and "extended-remote" on > Linux). I'd like tests automatically detect whether syscall catchpoint is supported, instead of hard-coded some unsupported targets. We can insert a syscall catchpoint and resume the inferior, warning "warning: Error inserting catchpoint 2: Your system does not support this t= ype" can tell us that syscall cachtpoint isn't supported. It is similar for detecting tracepoint support. > > [target_info exists use_gdb_stub] alone would work for the attach > tests, I am afraid not. attach tests should be skipped on remote host testing (build !=3D host, host =3D=3D target) too, because test program is spawned = on build, and the corresponding pid (on build) is used for gdb (on host) to attach. > which we want to skip for remote but run for extended-remote. This > (use_gdb_stub) seems to be equivalent to my new proc > [gdb_using_remote_protocol], meaning "using gdbserver/stub" and protocol > =3D=3D "remote". The name use_gdb_stub is misleading, since it is only s= et > for the remote protocol and not the extended protocol. Things go wrong > in lib/gdb.exp if you set use_gdb_stub and run extended-mode tests. > > If we put aside the fact that we can control the results of is_remote by > setting the variable isremote in the board file, then [isnative] and > [is_remote] don't provide the information we really need. In the > example above they are checking whether build!=3Dtarget and build!=3Dhost, > respectively. That doesn't cover all the cases, e.g. if build !=3D target > and build !=3D host, we don't know for sure whether target =3D=3D host. > > We can set isremote in the board files, as in native-gdbserver.exp, to > control what is_remote returns. But checking if we are using gdbserver > or a stub is not the purpose of is_remote, and trying to use it in > general for that could have negative side-effects (e.g. to gcc tests). > > My conclusion from all of this is that we should never use isnative or > is_remote to decide whether to skip tests for remote targets. The two > new proc's are testing the specific conditions that affect the remote > tests. We could use [target_info exists use_gdb_stub] in place of > [gdb_using_remote_protocol], but the name may be misleading. > > What do you think? In any case I'd like this discussion to result in a > standard approach for skipping remote tests for each of the relevant case= s. Some tests have to be skipped on remote targets, and even on other targets. I'd like to list all of them (tests having troubles running on remote target), and then figure out how to fix them. We can use a standard approach if necessary. --=20 Yao (=E9=BD=90=E5=B0=A7)