From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9666 invoked by alias); 28 Mar 2011 17:11:29 -0000 Received: (qmail 9649 invoked by uid 22791); 28 Mar 2011 17:11:27 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Mar 2011 17:11:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id CF4532BADF8; Mon, 28 Mar 2011 13:11:20 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U3pgiydyDe2S; Mon, 28 Mar 2011 13:11:20 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 62C142BAD9E; Mon, 28 Mar 2011 13:11:20 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 6D311145869; Mon, 28 Mar 2011 10:11:16 -0700 (PDT) Date: Mon, 28 Mar 2011 18:34:00 -0000 From: Joel Brobecker To: Ulrich Weigand Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [rfc, arm] Always use correct execution state for single-step breakpoints Message-ID: <20110328171116.GC3670@adacore.com> References: <4D8FE64E.3030409@codesourcery.com> <201103281315.p2SDFg3F004550@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103281315.p2SDFg3F004550@d06av02.portsmouth.uk.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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-03/txt/msg01133.txt.bz2 > > > +if ![runto_main] then { > > > + gdb_suppress_tests > > > +} We decided a long time ago that gdb_suppress_entire_file, gdb_suppress_tests et al should no longer be used... > > I am OK with part, but a question on general handling `failed to > > runto_main'. I noticed there are some different policies to handle > > that, such as `fail and return', `perror and return', and > > 'gdb_suppress_tests'. Which on is recommended? > > I don't really have a strong opinion on that, except that perror is > probably wrong (this is supposed to be uses to signal problems in > the test *framework* itself). I'd say that if there is a reasonable > expectation that starting up the test may fail on some platforms, > a failure of runto_main ought to trigger something like UNTESTED > or UNSUPPORTED. Otherwise it should trigger a FAIL. What we document right now is: if ![runto_main] { return -1 } (http://sourceware.org/gdb/wiki/GDBTestcaseCookbook) We might have discussed it, but I'm not sure. I see your point about posting an UNTESTED OR UNSUPPORTED, which I think prepare_for_testing does. In fact, an old message (from most likely DanielJ, in 2006): > I've been using untested followed by return. Why wouldn't that be > ideal? So, if that's agreeable to everyone, I will change the Cookbook to follow that. -- Joel