From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29727 invoked by alias); 24 Jun 2006 07:08:50 -0000 Received: (qmail 29719 invoked by uid 22791); 24 Jun 2006 07:08:49 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Jun 2006 07:08:47 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 4D25748CDAB; Sat, 24 Jun 2006 03:08:44 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06836-03-10; Sat, 24 Jun 2006 03:08:44 -0400 (EDT) Received: from takamaka.act-europe.fr (s142-179-108-108.bc.hsia.telus.net [142.179.108.108]) by nile.gnat.com (Postfix) with ESMTP id ECF0B48CBD6; Sat, 24 Jun 2006 03:08:43 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id F1DD547E7F; Sat, 24 Jun 2006 00:08:42 -0700 (PDT) Date: Sat, 24 Jun 2006 07:11:00 -0000 From: Joel Brobecker To: gdb@sources.redhat.com, Paul Koning Subject: Re: Should "dir" override the full path encoded in debug info? Message-ID: <20060624070842.GC22750@adacore.com> References: <20060623201019.GX22750@adacore.com> <20060623201839.GA2920@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060623201839.GA2920@nevyn.them.org> User-Agent: Mutt/1.4i 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: 2006-06/txt/msg00205.txt.bz2 > It is quite likely that what you really want is not "dir", but this: > > http://sourceware.org/ml/gdb/2006-03/msg00189.html > > Hey, Paul... Indeed, that would solve the proble entirely. I wonder how this should be implemented... Should the command store the rewriting rule, and have find_and_open_source() use it when trying to locate source files? > This might be a bug, or it might not. But generally "dir" is used only > for files which could not be found; first try the normal location, then > try the search path. This is the same thing we do for shared libraries > (which implies that the new command would be sort-of an analog for set > solib-absolute-prefix). Changing anything here is tricky, because of > the case of multiple directories with files with the same name... Indeed, same file name used more than once in a project is an issue. Perhaps the argument I was making saying that it "works" in most cases is backwards, and it actually "works" in my coworker's case while it's broken for most cases. I'm not sure I would thrilled at the prospect of fixing this, knowing how delicate this can be. -- Joel