From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25122 invoked by alias); 18 Dec 2014 12:16:48 -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 25110 invoked by uid 89); 18 Dec 2014 12:16:47 -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,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 18 Dec 2014 12:16:46 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBICGg7s005508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 18 Dec 2014 07:16:42 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBICGeO6020678; Thu, 18 Dec 2014 07:16:41 -0500 Message-ID: <5492C5A8.2020600@redhat.com> Date: Thu, 18 Dec 2014 12:16:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yao Qi , "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> <87mw6pt98q.fsf@codesourcery.com> In-Reply-To: <87mw6pt98q.fsf@codesourcery.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-12/txt/msg00520.txt.bz2 I see now we're discussing the same things here: https://sourceware.org/ml/gdb-patches/2014-12/msg00507.html On 12/15/2014 11:58 AM, Yao Qi wrote: >> [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 != host, host == target) too, because test program is spawned on > build, and the corresponding pid (on build) is used for gdb (on host) to > attach. As I mentioned in the other email, in that scenario, build != target too, so an is_remote target check already causes it to be skipped. In the (build != host, build == target) scenario, the program is spawned on the target, and although gdb runs on a different machine from where the target programs run, the PID that is passed to gdb is a target pid (e.g., debugging with extended-remote). So in that scenario, the test should be able to run. But if we checked "is_remote host", it wouldn't. >> 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 >> == "remote". It means "use stub-like mechanisms". IOW, "when gdb connects, the program is already running, because the debug agent is really a piece of code (stub) that runs inside the target program". GDB used to support a bunch more remote protocols that we've been dropping over the years. And then GDBserver/"target remote" debugging behaves mostly like a real stub, so nowadays use_gdb_stub is it's mostly equivalent to "remote", though the former is more generic. >> The name use_gdb_stub is misleading, since it is only set >> 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. See above. The extended protocol does not behave like a stub. >> >> 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!=target and build!=host, >> respectively. That doesn't cover all the cases, e.g. if build != target >> and build != host, we don't know for sure whether target == host. True, but what are the cases where that matters? >> 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). Agreed. >> >> 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 cases. See https://sourceware.org/ml/gdb-patches/2014-12/msg00507.html. Thanks, Pedro Alves