Re: failures in fileio.exp

[Andrew Cagney <ac131313@redhat.com>]

>> My understanding from the thread discussing fileio.exp:
>> http://sources.redhat.com/ml/gdb-patches/2003-06/msg00410.html
>> was that it should work native.  Restricting it to the remote case would 
>> leave it open to bit rot.
>> 
>> The above indicate that this is true.  The differences are minor syscall 
>> nuances and can be handled with a bit of testsuite tweaking.
> 
> 
> It's totally nonsense to test on a native target.

The rationale for requesting that the test work native was that the test 
would otherwize bit rot.  I used remote.exp to illustrate my point.  It 
turned out, though that I could have used fileio.exp.  The following 
failures:

FAIL: gdb.base/fileio.exp: Renaming a nonexistant file returns ENOENT
FAIL: gdb.base/fileio.exp: Unlinking a nonexistant file returns ENOENT
FAIL: gdb.base/fileio.exp: Time(2) returns feasible values

were due to a big in the testsuite.  A line in the .c file got lost 
somewhere and that lead to the 'tbreak N' missing the mark. 
get_get_line_number is good for this.

>  In that case you're
> testing the operating system, not the fileio protocol, which is the
> task of that test.

This is a system level test.  A file-io protocol test would involve 
``set debug remote 1'' and then check that the packets were to spec.

> Tweaking the testcase is even making things worse
> since it's *strictly* defined how the fileio code works and what
> return codes and error codes are expected.  If you're going to weaken
> the testcase by allowing different results just for the sake of running
> a useless test, that's IMHO counterproductive.

True.  But only if the changes were to weaken the test.  It not working 
is an indication of a bug in GDB, or the testsuite.

Andrew