From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20837 invoked by alias); 6 Oct 2005 00:57:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20830 invoked by uid 22791); 6 Oct 2005 00:57:52 -0000 Received: from chfw.preston.net (HELO universe.preston.net) (202.14.89.130) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 06 Oct 2005 00:57:52 +0000 Received: from norman (norman.preston.net [202.14.10.82]) by universe.preston.net (8.11.6/8.11.6) with ESMTP id j960vBh04147; Thu, 6 Oct 2005 10:57:11 +1000 Subject: Re: [PATCH] Relative source file search From: Craig Jeffree To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com In-Reply-To: <20051004013535.GA24000@nevyn.them.org> References: <1127806796.32709.17.camel@norman> <1128389039.32709.128.camel@norman> <20051004013535.GA24000@nevyn.them.org> Content-Type: text/plain Date: Thu, 06 Oct 2005 00:57:00 -0000 Message-Id: <1128560230.18954.14.camel@norman> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-10/txt/msg00052.txt.bz2 On Mon, 2005-10-03 at 21:35 -0400, Daniel Jacobowitz wrote: > I took a brief look at it, and felt that it was in the wrong place, > i.e. belonged in openp. I haven't had a chance to come back to it yet. > I considered this, however the information provided by the symtab doesn't fit with this. In the case that I'm experiencing I start up GDB with a binary and issue this dir command: dir /staff/taam/taam/bin/x86-Linux/nostrip/ which is the directory where the application was built. When I do a "list GeAttribute.H:1" and break GDB at the start of open_source_file() I get the following information in the symtab: s->filename = "GeAttribute.H" s->dirname = "../../../include/General" s->fullname = 0x0 This dirname/filename concatenation is correct if taken relative to the binary location added to the directory search path. So open_source_file() calls find_and_open_source() which replaces "$cdir" in the source search path with the value from s->dirname. However this means the file cannot be found because openp() then searches for the filename in each of the directories in the source search path but this path now contains a relative path that depends on one of the other entries in the path. I don't think it makes sense for openp to start fiddling around with combinations of directories from the path, however I can understand wanting to move this into find_and_open_source() since open_source_file () is meant to be a convenience function. Would a move to find_and_open_source() instead of openp() be acceptable? Cheers, Craig.