From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121789 invoked by alias); 8 Oct 2018 02:25: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 121637 invoked by uid 89); 8 Oct 2018 02:25:02 -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=emaisin, continuing, messy, linking 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; Mon, 08 Oct 2018 02:25:00 +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 w982OqlB024123 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 7 Oct 2018 22:24:56 -0400 Received: by simark.ca (Postfix, from userid 112) id 0C2EC1EA6C; Sun, 7 Oct 2018 22:24:52 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id BD5AA1E52B; Sun, 7 Oct 2018 22:24:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 08 Oct 2018 02:25: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: <3f5d484c-d001-0447-ebb9-9e906218a5f7@codesourcery.com> References: <3f5d484c-d001-0447-ebb9-9e906218a5f7@codesourcery.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00167.txt.bz2 On 2018-10-06 21:09, Sandra Loosemore wrote: > Continuing through my pile of testsuite problems found while working > on cleaning up nios2 test results.... > > I found that the results for the gdb.trace tests were really messy on > targets that don't support the trace features. The trouble affected > various other embedded targets I tried, not just nios2. Specific > problems included: > > * The header file trace-common.h that is used by most of the test > programs in this directory causes multiple compilation errors (not > just the obvious preprocessor #error) on architectures it doesn't know > about, and the checks in the .exp files for successful compilation of > the test case didn't distinguish between failures for missing arch > support (should have "unsupported" status) and failures due to unknown > causes (should be "untested"). My understanding is that adding arch > support to trace-common.h won't do anything useful without > implementing the underlying fast tracepoint support too. > > * Several test cases depend on linking with/loading a shared library > for in-process trace without checking for shared library support on > the target. > > * The signal.exp test case didn't test for signal support. > > * The tspeed.c test case was failing to compile due to a missing > #include, and its .exp file did not test for runtime target support in > gdb. > > Anyway.... here's an attempt to fix all this. I added an early test > for arch support to the .exp files so that most tests report > "unsupported" immediately when they cannot possibly work, and fixed up > the other problems as needed. > > OK to check in? > > -Sandra Hi Sandra, Thanks for this, fixes to make the testsuite run more cleanly is always appreciated. I just did a quick smoke check, and noticed some errors when running on x86: Running /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.trace/signal.exp ... ERROR: no fileid for elxacz23q12 (elxacz23q12 is my hostname) This looks like a check done a bit too early. Can you make sure that these tests: $ make check TESTS="gdb.trace/*.exp" $ make check TESTS="gdb.trace/*.exp" RUNTESTFLAGS="--target_board=native-gdbserver" $ make check TESTS="gdb.trace/*.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver" Don't have significant differences before/after your patch (on x86/Linux)? If you don't see any difference, maybe the problem is on my side, then I'll look into it. Simon