From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89527 invoked by alias); 11 Oct 2018 05:19:56 -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 89516 invoked by uid 89); 11 Oct 2018 05:19:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=bare-metal 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; Thu, 11 Oct 2018 05:19:54 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gATO4-0003Ry-GU from Sandra_Loosemore@mentor.com ; Wed, 10 Oct 2018 22:19:52 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 10 Oct 2018 22:19:49 -0700 Subject: Re: [patch, testsuite] Clean up gdb.trace results To: Simon Marchi CC: References: <3f5d484c-d001-0447-ebb9-9e906218a5f7@codesourcery.com> <8abc8c2c-150c-99d9-e0d5-992225a8cac5@codesourcery.com> <6bbd680801f5aaf7709633e51c4a6d11@polymtl.ca> From: Sandra Loosemore Message-ID: <7bf12e32-9e47-3ff1-3092-303dfdff98ff@codesourcery.com> Date: Thu, 11 Oct 2018 05:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6bbd680801f5aaf7709633e51c4a6d11@polymtl.ca> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-10/txt/msg00270.txt.bz2 On 10/10/2018 10:08 PM, Simon Marchi wrote: > 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. If the architecture isn't one of those supported by trace-common.h, then actions.c (or any other program that includes trace-common.h) won't compile. E.g. here is a recent gdb.sum extract for nios2-elf (using gdb 8.2 branch): Running /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.exp ... gdb compile failed, In file included from /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.c:24: /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/trace-common.h:61:2: error: #error "unsupported architecture for trace tests" #error "unsupported architecture for trace tests" ^~~~~ /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.c: In function 'main': /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.c:146:26: error: 'fast_tracepoint_loc' undeclared (first use in this function) FAST_TRACEPOINT_LABEL (fast_tracepoint_loc); ^~~~~~~~~~~~~~~~~~~ /scratch/sandra/nios2-elf-fall-preview/src/gdb-master-8.2/gdb/testsuite/gdb.trace/actions.c:146:26: note: each undeclared identifier is reported only once for each function it appears in UNTESTED: gdb.trace/actions.exp: failed to compile My patch does not change what targets the tests work on, it only makes it fail gracefully with UNSUPPORTED instead of spewing a bunch of compilation errors into the gdb.sum file and reporting UNTESTED. > 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? Well, the particular use case I've been looking at are nios2-linux-gnu and nios2-elf, and seeing my gdb.sum files full of random compilation errors and TCL ERRORs where I think it should just be reporting UNSUPPORTED. Most of the compilation errors are coming from trace-common.h, and as I said, I'm under the impression that making this work involves adding target hooks to gdb and/or gdbserver and not just adding some stub for the arch to trace-common.h to prevent it from hitting the preprocessor #error and undefined symbol errors. I'm really not even clear on the difference between "tracepoints" and "fast tracepoints" is, or which things which testcases are trying to test. IMO the problem here is that these tests were written with the assumption that the all support is present -- not just the tracepoint support, but things like shared libraries and signals that typically aren't supported on bare-metal targets, so they're just failing in really ugly ways when the necessary support isn't there. -Sandra