From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2476 invoked by alias); 5 May 2011 15:59:21 -0000 Received: (qmail 2468 invoked by uid 22791); 5 May 2011 15:59:20 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 May 2011 15:59:06 +0000 Received: (qmail 24471 invoked from network); 5 May 2011 15:59:06 -0000 Received: from unknown (HELO ?192.168.1.4?) (janisjo@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 May 2011 15:59:06 -0000 Message-ID: <4DC2C957.2070307@codesourcery.com> Date: Thu, 05 May 2011 15:59:00 -0000 From: Janis Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Kettenis CC: gdb-patches@sourceware.org Subject: Re: [RFA] bailing out of tests with multiple errors or timeouts References: <4DC1910A.8040603@codesourcery.com> <201105041810.p44IAVlq008135@glazunov.sibelius.xs4all.nl> In-Reply-To: <201105041810.p44IAVlq008135@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2011-05/txt/msg00138.txt.bz2 On 05/04/2011 11:10 AM, Mark Kettenis wrote: >> Date: Wed, 04 May 2011 10:46:50 -0700 >> From: Janis Johnson > >> + timeout { >> + # A timeout here often indicates more timeouts later in the test. >> + fail "$test (timeout)" >> + fail "Remainder of test" >> + return >> + } > > Often, so not always. Really the best way to get rid of these is to > fix the underlying problem. I agree, the best way to get rid of timeouts and ERRORs in gdb tests is to fix gdb. Unfortunately, that's not an easy task for a target whose support is buggy or incomplete whether in gdb, simulator, hardware, or operating system. It's painful to test on such targets when a few tests time out multiple times. What I'm looking for is a way to bail out of tests that are known to time out multiple times on some targets, or have a cascade of ERRORs. That might involve changes to specific tests like the examples I posted; it might involve setting a magic variable somewhere to bail out of any test that times out or runs into an error; it might involve having a list of tests that bail out after a timeout or error. Ideally there would be an easily-recognizable failure message for those tests to indicate it's more than a normal failure; maybe UNRESOLVED. I'm not familiar enough with the workings of the gdb test infrastructure or the general conventions of the gdb testsuite to know what might be appropriate, but presumably others have run into this problem and have ideas. Janis Johnson CodeSourcery / Mentor Graphics