From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42618 invoked by alias); 11 Oct 2018 04:08:21 -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 42603 invoked by uid 89); 11 Oct 2018 04:08:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Oct 2018 04:08:19 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w9B48DvL022781 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 11 Oct 2018 00:08:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 6C3001EA6D; Thu, 11 Oct 2018 00:08:13 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id CBCA41E4C2; Thu, 11 Oct 2018 00:08:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 11 Oct 2018 04:08:00 -0000 From: Simon Marchi To: Sandra Loosemore Cc: gdb-patches@sourceware.org Subject: Re: [patch, testsuite] Clean up gdb.trace results In-Reply-To: <8abc8c2c-150c-99d9-e0d5-992225a8cac5@codesourcery.com> References: <3f5d484c-d001-0447-ebb9-9e906218a5f7@codesourcery.com> <8abc8c2c-150c-99d9-e0d5-992225a8cac5@codesourcery.com> Message-ID: <6bbd680801f5aaf7709633e51c4a6d11@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00269.txt.bz2 On 2018-10-10 22:01, Sandra Loosemore wrote: > Thanks, I tried that and made a couple tweaks to the patch to fix > those errors. Is this version OK? > > -Sandra Hi Sandra, I'd just like to understand the situation a bit more. From what I understand, trace-common.h is only useful for fast tracepoint tests. Let's take the actions.exp test, for example. It uses actions.c, which includes trace-common.h, therefore you added a gdb_trace_common_supports_arch check. However, actions.exp does not rely on fast tracepoint support at all. actions.c happens to be used by another test that tests fast tracepoints. The result is that if an architecture supports tracepoints, but not fast tracepoints, the actions.exp test will be skipped even though it would be relevant. Trying to read between the lines: if your target did not support tracepoints at all, then the gdb_target_supports_trace calls would be enough. If your target did support regular and fast tracepoints, then you would just add support for it in trace-common.h, because you would want to run the fast tracepoint tests. So the remaining combination is that your target supports regular tracepoints, but not fast tracepoints. Is it the case? If so, I think the right fix would be to untangle fast tracepoints tests from regular tracepoints tests. The goal being to make it possible to run as many tests as possible against targets that only support regular tracepoints. Or maybe I'm completely lost, in which case can you clarify what your use case is? Thanks, Simon