This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa/testsuite] Don't display values in output of pc-fp.exp


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]