From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31123 invoked by alias); 24 Aug 2005 11:24:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31089 invoked by uid 22791); 24 Aug 2005 11:24:19 -0000 Received: from eastrmmtao05.cox.net (HELO eastrmmtao05.cox.net) (68.230.240.34) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 24 Aug 2005 11:24:19 +0000 Received: from white ([68.9.64.121]) by eastrmmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050824112418.QMMN15295.eastrmmtao05.cox.net@white>; Wed, 24 Aug 2005 07:24:18 -0400 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1E7tMf-0007rc-00; Wed, 24 Aug 2005 07:24:17 -0400 Date: Wed, 24 Aug 2005 11:24:00 -0000 From: Bob Rossi To: Craig Jeffree Cc: gdb@sources.redhat.com Subject: Re: trouble locating source files through relative paths Message-ID: <20050824112417.GA30211@white> Mail-Followup-To: Craig Jeffree , gdb@sources.redhat.com References: <1124436292.3582.64.camel@norman> <20050819124329.GA18911@white> <1124773410.3749.38.camel@norman> <20050823113138.GA27899@white> <20050823114028.GB27899@white> <1124866437.3749.75.camel@norman> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1124866437.3749.75.camel@norman> User-Agent: Mutt/1.5.9i X-SW-Source: 2005-08/txt/msg00092.txt.bz2 On Wed, Aug 24, 2005 at 04:53:57PM +1000, Craig Jeffree wrote: > On Tue, 2005-08-23 at 07:40 -0400, Bob Rossi wrote: > > I'll look into this. > > It looks like find_and_open_source() could be modified to check if > dirname is relative and if so call openp with dirname prepended to > filename instead of modifying the search path. > > I think this is what Dave Korn suggested earlier, except he proposes > identifying the relative link before the call to find_and_open_source > and avoiding the split at that point. However, this might result in > checks occuring in multiple places - I haven't looked for this. > > I'm not familiar with the gdb source so I'm not sure which solution will > be more appropriate. Putting the fix in find_and_open_source() would be > more self contained, however this might affect other clients of > find_and_open_source() in ways I haven't considered. Well, I haven't had enough time to investigate this more, however, I did find some odd results with the example I came up with. For example, if I do 'info sources' before the dir command is applied, GDB spits out the relative path. However, if I do the dir command, and then do 'info sources', then GDB spits out the absolute path. Once GDB has the absolute path, if I then do 'list uut.h:1', GDB can still not find the file. If I do 'list ../include/uut.h:1', then I get an Internal GDB error. Do you get these same results? If so, find_and_open_source is finding the fullname, even though things are still not working properly. Hopefully I'll have more time to look into this today. Thanks, Bob Rossi