From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32407 invoked by alias); 5 May 2005 18:52:09 -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 31822 invoked from network); 5 May 2005 18:51:58 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 5 May 2005 18:51:58 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DTlS1-0005at-LC for ; Thu, 05 May 2005 14:51:57 -0400 Date: Thu, 05 May 2005 18:52:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: again: ping: testcase for "absolute source" patch Message-ID: <20050505185156.GA20152@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20050505110048.GC5840@radix50.net> <20050505111117.GD5840@radix50.net> <20050505110048.GC5840@radix50.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505111117.GD5840@radix50.net> <20050505110048.GC5840@radix50.net> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00174.txt.bz2 On Thu, May 05, 2005 at 01:00:48PM +0200, Baurzhan Ismagulov wrote: > Hello, > > the recent discussion reminded me about the testcase I submitted in > http://sources.redhat.com/ml/gdb-patches/2004-08/msg00539.html . While > unrelated, it did help me understand the issue. There are relatively few > basic cases (like absolute / relative, compilation cwd present / absent, > etc., search path specified / not specified, etc.), it's their > permutations that kill. While the testcase doesn't cover them all, I > think it's a good start, especially if we are going to touch some > functionality affecting openp. The functionality is very basic and > breaks everything if anything goes wrong; it happened several times in > the past, thus the motivation for this testcase. We don't plan to touch openp right now; but let's test it, by all means. > A short history: Michael Chastain was guiding me w.r.t. this testcase. > Basically, he had three issues with it: > > 1. The testcase didn't support build != host. > > The overall consensus was that there were useful testcases that > didn't support build != host at the moment. Michael decided to > include them if they explicitly returned unresolved on remote hosts. > I added the check. Lately we've been caring about this even less. > 3. There were four cases where I was not sure what we wanted to do, so I > marked them "fail". > > I asked for feedback several times, but haven't received any answer. Adding new FAILs is not ok; at a minimum they should have a PR filed and be KFAIL'd. But let's take a brief check to see what the logical thing to do would be. Here's the reference: http://sources.redhat.com/ml/gdb-patches/2004-08/msg00539.html If I understand the test right - which is hard to do, definitely - these cases look like: cd $a gcc -g -o $b/openp.bin openp.c mv openp.c $c/$a/openp.c (gdb) dir $c (gdb) file $b/openp.bin And then you fail because we didn't search for the absolute path $a relative to $c, which is in our search path. I don't think there's much value to this, if $cdir is an absolute path. If it's a relative path, maybe, but your compiler oughtn't to be doing that. Can you explain why you think this should work? I do know of some problems with openp that are sort of like this - I encounter them periodically debugging glibc. They're a little similar but related, and you might want to add tests for them. Here's one: drow@nevyn:~/dir% pwd /home/drow/dir drow@nevyn:~/dir% cat 1/1.c #include <../2/2.h> int main() { return 0; } drow@nevyn:~/dir% cat 2/2.h int foo() { return 1;} drow@nevyn:~/dir% (cd 1 && gcc -g -o 1 1.c -I.) drow@nevyn:~/dir% (cd 1 && gdb 1) ... (gdb) list foo 1 int foo() { return 1;} drow@nevyn:~/dir% gdb ./1/1 ... (gdb) list foo 1 2.h: No such file or directory. in 2.h (gdb) info source Current source file is 2.h Compilation directory is ../2 ... Current source file is 1.c Compilation directory is /home/drow/dir/1 We've lost the fact that "../2" is relative to the compilation directory for the main source file; I'm not sure if this is a dwarf2 reader bug or a symtab bug or an openp bug. But it bugs me. A lot. > So, I suggest that we review, polish and include this testcase. After > that, we can test it on more platforms and add new permutations for > non-POSIX names. > > Comments? You're including pathnames in the test results. I'd really rather you didn't do that; it makes results hard to compare, and really really hard to read. Also, a lot of the tests have shortened names like "s1" but those names don't tell the reader anything. So in some places you need to be less descriptive and in others more descriptive. Ideally I can fit the descriptions on a screen (80-col plus or minus a bit) and yet still have some idea what they are testing. -- Daniel Jacobowitz CodeSourcery, LLC