From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17742 invoked by alias); 6 Dec 2005 20:11:21 -0000 Received: (qmail 17735 invoked by uid 22791); 6 Dec 2005 20:11:20 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Dec 2005 20:11:18 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-29-207.inter.net.il [80.230.29.207]) by romy.inter.net.il (MOS 3.7.2-GA) with ESMTP id DCX50231 (AUTH halo1); Tue, 6 Dec 2005 22:11:14 +0200 (IST) Date: Tue, 06 Dec 2005 20:11:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus , gdb@sources.redhat.com In-reply-to: <20051206045518.GA23837@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 5 Dec 2005 23:55:18 -0500) Subject: Re: Filename with "./" in breakpoint command Reply-to: Eli Zaretskii References: <200512050953.01350.ghost@cs.msu.su> <20051205185556.GA9808@nevyn.them.org> <20051206045518.GA23837@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00061.txt.bz2 > Date: Mon, 5 Dec 2005 23:55:18 -0500 > From: Daniel Jacobowitz > Cc: Vladimir Prus , gdb@sources.redhat.com > > On Tue, Dec 06, 2005 at 06:27:37AM +0200, Eli Zaretskii wrote: > > > Date: Mon, 5 Dec 2005 13:55:56 -0500 > > > From: Daniel Jacobowitz > > > Cc: Vladimir Prus , gdb@sources.redhat.com > > > > > > Or, when the existing lookups have failed for a relative pathname, > > > canonicalize it and treat it like a full path? > > > > I don't like that, since it requires to chdir to some directory first. > > Could you explain why not? GDB already has a notion of $cdir, and it > seems logical to me that if the user types "./foo.c" they mean for that > to be relative to $cdir, but I certainly could be missing something. I didn't say that "./foo.c" shouldn't resolve to the file in the current working directory, I'm saying that it is not, IMHO, a good solution of the original problem. The original problem was _not_ that "./foo.c" didn't do what the user expected; "./foo.c" was an attempt of _solving_ a problem. And the problem the OP tried to solve was that there were several source files linked into the executable, each one in its own directory. I don't like telling the user to go to some directory to solve that original problem. For starters, it requires the user to type the full name of the directory, which is almost like asking them to type the full file name of the source file. I'd prefer to have a better solution to the original problem.