From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15032 invoked by alias); 12 Jan 2007 03:24:06 -0000 Received: (qmail 15013 invoked by uid 22791); 12 Jan 2007 03:24: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; Fri, 12 Jan 2007 03:23:58 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H5D1I-0002MA-5m; Thu, 11 Jan 2007 22:23:56 -0500 Date: Fri, 12 Jan 2007 03:24:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb@sourceware.org Subject: Re: substitute-path problem Message-ID: <20070112032356.GA8983@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb@sourceware.org References: <20070112025149.GA7621@nevyn.them.org> <20070112032112.GO23012@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070112032112.GO23012@adacore.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00202.txt.bz2 On Fri, Jan 12, 2007 at 07:21:12AM +0400, Joel Brobecker wrote: > (I have wondered many times how much easier it would be for us if > we resolved the filename+dirname into a fullpath name at debug info > reading time, and then only stored that in our data structures - not > sure if it is posssible, but if it is, we would be able to assume in > the rest of the code that symbol->filename is always a fullpath, or > the closest to it we can do based on the information the compiler provided. > But I think that would change the behavior of certain things like source > file search with the dir path. I'm not completely sure yet, I would have > to spend some time researching this) Yes, this code is complicated and messy and really way too error prone; the two cases should be the same. This all ties in with the patch Jan just posted (which I admit that I read, but could not make heads or tails out of). We need to make the two cases follow the same code path or we'll keep breaking one of them. It turns out find_and_open_source does plenty of other things wrong too with dirname == NULL. I saw it try to open "$cdir/scratch" (literally) and also "/home/drow/scratch". Not sure if that's really on purpose... but the latter and a handy symlink solved my immediate problem :-) BTW, if you have a chance to improve related things: help set substitute-path was very unhelpful. It doesn't say what the arguments should be. -- Daniel Jacobowitz CodeSourcery