From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4312 invoked by alias); 6 Oct 2005 02:16:09 -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 4279 invoked by uid 22791); 6 Oct 2005 02:16:02 -0000 Received: from eastrmmtao02.cox.net (HELO eastrmmtao02.cox.net) (68.230.240.37) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 06 Oct 2005 02:16:01 +0000 Received: from white ([68.9.64.121]) by eastrmmtao02.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051006021543.RBFU22723.eastrmmtao02.cox.net@white>; Wed, 5 Oct 2005 22:15:43 -0400 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1ENLIS-0001Ne-00; Wed, 05 Oct 2005 22:15:48 -0400 Date: Thu, 06 Oct 2005 02:16:00 -0000 From: Bob Rossi To: Craig Jeffree Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Relative source file search Message-ID: <20051006021548.GA5232@white> Mail-Followup-To: Craig Jeffree , Daniel Jacobowitz , gdb-patches@sources.redhat.com References: <1127806796.32709.17.camel@norman> <1128389039.32709.128.camel@norman> <20051004013535.GA24000@nevyn.them.org> <1128560230.18954.14.camel@norman> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1128560230.18954.14.camel@norman> User-Agent: Mutt/1.5.9i X-SW-Source: 2005-10/txt/msg00053.txt.bz2 On Thu, Oct 06, 2005 at 10:57:10AM +1000, Craig Jeffree wrote: > 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? Hi Craig, I've been thinking about this a little. Here's the documentation for explaining how the 'dir' command works. Plain file names, relative file names with leading directories, file names containing dots, etc. are all treated as described above; for instance, if the source path is `/mnt/cross', and the source file is recorded as `../lib/foo.c', GDB would first try `../lib/foo.c', then `/mnt/cross/../lib/foo.c', and after that---`/mnt/cross/foo.c'. This documentation describes the steps taken in order to find a file. It doesn't describe using the symtabs dirname field. As I look at the code in source.c:find_and_open_source I find that if dirname is not NULL, then source_path get's set to "dirname:$cwd", and if the user used the 'dir' command to add directory's you end up with "/home/dir1:/home/dir2:dirname:$cwd". So, if your dirname is relative, like "../include", and your filename is "foo.h", then moving your executable should not be a problem. I think the problem is where you start GDB from. I find that if I start GDB from where the executable original was, then it finds the file no problem. If you start GDB from somewhere else, then the relative path makes no sense to GDB. Can you try starting GDB from the correct location and see if this fixes your problem? Thanks, Bob Rossi