From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16010 invoked by alias); 6 Nov 2002 22:57:52 -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 16000 invoked from network); 6 Nov 2002 22:57:52 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 6 Nov 2002 22:57:52 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id gA6MvVw28252; Wed, 6 Nov 2002 14:57:31 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Michael Snyder Subject: Re: [rfa/testsuite] Don't display values in output of pc-fp.exp Cc: gdb-patches@sources.redhat.com, Fernando Nasser , cagney References: <3DC84C23.8070801@redhat.com> <3DC98B56.2861A478@redhat.com> From: David Carlton Date: Wed, 06 Nov 2002 14:57:00 -0000 In-Reply-To: <3DC98B56.2861A478@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00142.txt.bz2 On Wed, 06 Nov 2002 13:36:22 -0800, Michael Snyder said: [ Michael accidentally replied just to me rather than to the whole list, so others haven't seen his response yet. ] > David Carlton wrote: >> On Tue, 05 Nov 2002 17:54:27 -0500, Andrew Cagney said: >>> 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. > You should. You'll bang your head against this again. It's a > convention [Andrew: is this documented?] that the testsuites may > generate any random output so long as its in parentheses -- scripts > should ignore it. Fair enough. It may well be documented somewhere, actually: I didn't think to look. >> 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. > You're right. I don't think they belong there either. Okay. So it seems like, on the one hand, I should be more accepting of stuff in parentheses. But, on the other hand, tests shouldn't go out of their way to add stuff in parentheses, either: if it's something that a human reader is likely to find useful or if it's something where it's interesting if its value changes even if that doesn't count as a regression, then it's probably a good idea for it to be there. But I don't think that applies in this case. >>> Also, why is FP/PC changing? Your GDB changes shouldn't affect the >>> behavior of the target program's $fp / $pc. >> That's a good point; I hadn't thought of that. I'm actually not >> entirely sure what it is that leads to the value of $fp changing from >> test run to test run. > Is this native linux? Yup. >> But I will make the empirical observation that it does change from >> test run to test run, and I'd be shocked if those changes reflected >> introduction of new bugs into GDB. > PROBABLY not... but maybe it's actually a virtue that we've noticed them. > I'm curious what could account for them too. Things I can think of > include: > * running gdb under gdb (or some other debugger-like or prof-like tool) > * changing the size of the inferior's (or possibly gdb's) environment. > * running from the unix shell one time, but from a shell script another time. My guess is that it's the environment. I do 'make check' every once in a while (well, about every 15 minutes these days, but I won't be tinkering with linespec.c forever...), and I compare the resulting gdb.sum against the gdb.sum from the last time that the correct output changed. And that last copy could be days or even weeks old, so my environment could have easily changed in the interim. David Carlton carlton@math.stanford.edu