From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23257 invoked by alias); 14 Jun 2003 16:47:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23226 invoked from network); 14 Jun 2003 16:47:33 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 14 Jun 2003 16:47:33 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 159042B5F for ; Sat, 14 Jun 2003 12:47:24 -0400 (EDT) Message-ID: <3EEB519B.4010603@redhat.com> Date: Sat, 14 Jun 2003 16:47:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: failures in fileio.exp References: <20030612095036.GP30116@cygbert.vinschen.de> <3EE86D0F.8070409@redhat.com> <20030612122452.GR30116@cygbert.vinschen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00283.txt.bz2 >> 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