From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24663 invoked by alias); 5 Dec 2005 18:56:06 -0000 Received: (qmail 24656 invoked by uid 22791); 5 Dec 2005 18:56:05 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 05 Dec 2005 18:56:04 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EjLVE-0002gf-2j; Mon, 05 Dec 2005 13:55:56 -0500 Date: Mon, 05 Dec 2005 18:56:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: Filename with "./" in breakpoint command Message-ID: <20051205185556.GA9808@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Vladimir Prus , gdb@sources.redhat.com References: <200512050953.01350.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i 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/msg00046.txt.bz2 On Mon, Dec 05, 2005 at 08:39:37PM +0200, Eli Zaretskii wrote: > Thanks. > > Looking at symtab.c:lookup_symtab, I see that we simply don't try to > look for anything but the exact match when given a relative file name > such as "./tracepoints.cpp". > > I'm not sure this is a bug; the idea of asking the user to chdir into > the right directory and then use "./foo" to distinguish between > several namesake files doesn't sound like a very user-friendly design, > not really a big improvement over asking them to specify a full > absolute file name of the source (in which case it does work for you, > does it?). > > Perhaps we should modify the lookup_symtab to not return immediately > after finding the first matching tail (near line 174 in symtab.c), but > instead see if there's more than one match, and if so, ask the user > which one she wants. What do you think? Or, when the existing lookups have failed for a relative pathname, canonicalize it and treat it like a full path? I don't think adding more user interaction at this level is a good idea - it's too far away from the user commands, in GDB's internals. It's been back-burnered for lack of time, but I was working on patches to handle location lookups returning more than one location; e.g. setting breakpoints at all locations matching tracepoints.cpp:25. -- Daniel Jacobowitz CodeSourcery, LLC