From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9909 invoked by alias); 12 Oct 2018 21:36:19 -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 9892 invoked by uid 89); 12 Oct 2018 21:36:19 -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=boards, H*F:D*ca, H*u:1.3.6, H*UA:1.3.6 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; Fri, 12 Oct 2018 21:36:17 +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 w9CLaBGh028373 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 12 Oct 2018 17:36:15 -0400 Received: by simark.ca (Postfix, from userid 112) id 40C341EA6F; Fri, 12 Oct 2018 17:36:11 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 289B11E992; Fri, 12 Oct 2018 17:36:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 12 Oct 2018 21:36: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: <7bf12e32-9e47-3ff1-3092-303dfdff98ff@codesourcery.com> References: <3f5d484c-d001-0447-ebb9-9e906218a5f7@codesourcery.com> <8abc8c2c-150c-99d9-e0d5-992225a8cac5@codesourcery.com> <6bbd680801f5aaf7709633e51c4a6d11@polymtl.ca> <7bf12e32-9e47-3ff1-3092-303dfdff98ff@codesourcery.com> Message-ID: <5a1969ab48b5e4bc6ba823a868fed83b@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00300.txt.bz2 On 2018-10-11 01:19, Sandra Loosemore wrote: > 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. Ah I see. So to properly reproduce it (by faking it) on x86, I need to both make x86_supports_tracepoints return 0 and remove the x86-specific code in trace-common.h. If I do that, I see that indeed, the output is not pretty (lots of compilation failures + untested). > 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. That's true, and I'd say many tests are gdbserver-specific, since they load the in-process agent library. If somebody has a different gdb stub implementation that supports tracepoints, that would be a good candidate to clean up the testsuite further, making sure we only run gdbserver-specific tests when testing against the actual gdbserver. I have compared runs with/without your patch on x86 with the unix (default) and native-gdbserver boards, the results did not change. I then compared before/after runs using these boards but also mocking that tracepoints are not supported on x86, and the output is now much better. So the patch LGTM, thanks! Simon