From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18738 invoked by alias); 12 Oct 2004 14:07:08 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18569 invoked from network); 12 Oct 2004 14:07:03 -0000 Received: from unknown (HELO blount.mail.mindspring.net) (207.69.200.226) by sourceware.org with SMTP; 12 Oct 2004 14:07:03 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1CHNIc-0003mN-00; Tue, 12 Oct 2004 10:06:46 -0400 Received: from mindspring.com (unknown [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 7AFD84B359; Tue, 12 Oct 2004 09:37:08 -0400 (EDT) Date: Tue, 12 Oct 2004 14:07:00 -0000 From: Michael Chastain To: ibr@ata.cs.hun.edu.tr, gdb-patches@sources.redhat.com Subject: Re: Ping: Re: testcase for "absolute source" patch Message-ID: <416BDE03.nailLVC1EBCFD@mindspring.com> References: <20041002041152.GA2370@ata.cs.hun.edu.tr> In-Reply-To: <20041002041152.GA2370@ata.cs.hun.edu.tr> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00208.txt.bz2 Hi Baurjan, > All tests verify whether gdb finds (doesn't find) the files as expected. > To achieve that, we place them in some specific locations, such as > compilation directory, $PATH, gdb source path ("directory" command), > etc. The files from previous tests could cause false failures for the > tests where gdb is supposed not to find the file (all tests with '-'), > or false passes for the tests where gdb could find the wrong file (e.g., > in the compilation directory rather than in the source path). > > ... I decided to delete all files after each test, thus > making the tests independent of each other. > > ... each test expects to find the directory hierarchy in some > "standard" state (created til the line 206, just before the first > test_bin) and has to leave it in the same state. These would make good comments to add to the test script. Indeed, whenever the approval guy doesn't get something and the contributor has to explain it, that explanation is a good candidate for a comment in the source code. Okay, I am looking at gdb.log and there is not enough trace information about what directory is being tested. Can you add something like this to test_bin and test_src: proc test_bin () { ... if [catch {cd $gdb_wd} msg] { ... } pass "test_bin cd $gdb_wd" ... } That is not really a test; it's more of a marker for people who are reading gdb.log to figure out the tests. Also the ChangeLong entry should have your name and the date on it. Now for the substantive part ... I'm getting four FAIL results with gdb HEAD: gdb.base/openp.exp: openp s1-da (non-existent source, basename, find in /$cdir/basename) gdb.base/openp.exp: openp s3-da (non-existent source, relative name, find in /$cdir/relative) gdb.base/openp.exp: openp s4-da (non-existent source, in the current dir, find in /$cdir/basename) gdb.base/openp.exp: openp s5-da (non-existent source, in the upper dir, find in /$cdir/relative) Are these bugs in gdb or problems with the test script? I looked at the first one, s1-da, and it looks like a problem with the test script. The test program is compiled with the bare basename "openp.c". But there is no copy of openp.c in $gdb_wd, and $cmd1 is a gdb "dir" command for another directory where there is no openp.c. It looks like $gdb_resp for this test should not be "$src_txt", but something more like "1\topenp.c: No such file or directory\\..*". Or am I mis-reading something? Michael === * gdb.base/openp.c: New testcase. * gdb.base/openp.exp: New testcase checking for source, binary and compilation directory handling.