Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: David Carlton <carlton@math.stanford.edu>
To: Michael Snyder <msnyder@redhat.com>
Cc: gdb-patches@sources.redhat.com,
	Fernando Nasser <fnasser@redhat.com>, cagney <cagney@redhat.com>
Subject: Re: [rfa/testsuite] Don't display values in output of pc-fp.exp
Date: Wed, 06 Nov 2002 14:57:00 -0000	[thread overview]
Message-ID: <ro11y5ycnms.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <3DC98B56.2861A478@redhat.com>

On Wed, 06 Nov 2002 13:36:22 -0800, Michael Snyder <msnyder@redhat.com> 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 <ac131313@redhat.com> 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


      parent reply	other threads:[~2002-11-06 22:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-05 14:14 David Carlton
2002-11-05 14:17 ` Michael Snyder
2002-11-05 14:54 ` Andrew Cagney
2002-11-05 15:11   ` David Carlton
2002-11-05 15:20     ` Andrew Cagney
2002-11-05 15:41     ` Andrew Cagney
     [not found]     ` <3DC98B56.2861A478@redhat.com>
2002-11-06 14:57       ` David Carlton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ro11y5ycnms.fsf@jackfruit.Stanford.EDU \
    --to=carlton@math.stanford.edu \
    --cc=cagney@redhat.com \
    --cc=fnasser@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox