From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18890 invoked by alias); 5 Nov 2002 23:41:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18883 invoked from network); 5 Nov 2002 23:41:53 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 5 Nov 2002 23:41:53 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5D7A43F3E; Tue, 5 Nov 2002 18:41:53 -0500 (EST) Message-ID: <3DC85741.6090801@redhat.com> Date: Tue, 05 Nov 2002 15:41:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Carlton Cc: gdb-patches@sources.redhat.com, Fernando Nasser , cagney Subject: Re: [rfa/testsuite] Don't display values in output of pc-fp.exp References: <3DC84C23.8070801@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00081.txt.bz2 > On Tue, 05 Nov 2002 17:54:27 -0500, Andrew Cagney said: > > >>> The tests in pc-fp.exp display the actual values of $pc and $fp in >>> their PASS messages. That makes regression testing a bit more >>> annoying for me: the value of $fp changes with every change I make >>> to GDB. Is it okay to tweak the PASS messages not to display those >>> values? > > >> As far as I know, anything in trailing paren should be ignored when >> comparing test results. You might want to tweak your script (I've >> attached mine) to do this. > > > Wow: your script is complicated. I just do > > diff -u (first file) (second file) | grep -v schedlock > > I could do something more complicated than that, of course; on the > other hand, I'm still not convinced that I should. It seems to me > that details like the value of the variables in question shouldn't be > in gdb.sum: if I want that level of information, I'll look in gdb.log. > I think there's a virtue in having gdb.sum in a format that's easily > checkable without worrying about parsing issues: the easier it is to > do regression testing, the more often it will happen. Ah, you've never had to cross compare 64 different targets to check that their results are equivalent :-) Andrew