This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: failures in fileio.exp
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