From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15832 invoked by alias); 28 Jul 2010 21:43:03 -0000 Received: (qmail 15823 invoked by uid 22791); 28 Jul 2010 21:43:03 -0000 X-SWARE-Spam-Status: No, hits=-2.1 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; Wed, 28 Jul 2010 21:42:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 514E82BAC16; Wed, 28 Jul 2010 17:42:58 -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 84w8WYgRjRI4; Wed, 28 Jul 2010 17:42:58 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 1AF9B2BAC07; Wed, 28 Jul 2010 17:42:58 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 5094FF58FA; Wed, 28 Jul 2010 14:42:52 -0700 (PDT) Date: Wed, 28 Jul 2010 21:43:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Thiago Jung Bauermann , gdb-patches ml Subject: Re: [RFA] Fix setting of VSX registers Message-ID: <20100728214252.GY13267@adacore.com> References: <1279738729.11022.23.camel@hactar> <1280165485.2661.85.camel@hactar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 2010-07/txt/msg00527.txt.bz2 > One approach would be to refactor these procs so that your use can work. > I think this would be nice to have -- I think it would be good to have > fewer boilerplate tests with "synthetic" names, ones that nobody is > interested in. When we discussed the new gdb-testsuite that AdaCore uses, we talked about that quite a bit. And unsurprisingly, there was no obvious answer. These tests can be an annoyance if all hell breaks lose and they all start to fail. A PASS indeed adds little value to the results. But on the other hand, I have always felt that we should verify that these commands have the expected results, and that we should get a FAIL if we detect something went wrong. Ideally, we wanted to be able to group a sequence of commands as one "setup phase" and generate one FAIL if part of the sequence fails. But in the end, we decided that it was just simpler to treat everything as a test (this is what I have pretty much done in dejagnu as well). -- Joel