From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26037 invoked by alias); 6 Oct 2005 02:49:45 -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 26029 invoked by uid 22791); 6 Oct 2005 02:49:43 -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 02:49:43 +0000 Received: from norman (norman.preston.net [202.14.10.82]) by universe.preston.net (8.11.6/8.11.6) with ESMTP id j962mch08211; Thu, 6 Oct 2005 12:48:38 +1000 Subject: Re: [PATCH] Relative source file search From: Craig Jeffree To: Bob Rossi Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com In-Reply-To: <20051006021548.GA5232@white> References: <1127806796.32709.17.camel@norman> <1128389039.32709.128.camel@norman> <20051004013535.GA24000@nevyn.them.org> <1128560230.18954.14.camel@norman> <20051006021548.GA5232@white> Content-Type: text/plain Date: Thu, 06 Oct 2005 02:49:00 -0000 Message-Id: <1128566917.18954.39.camel@norman> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-10/txt/msg00054.txt.bz2 On Wed, 2005-10-05 at 22:15 -0400, Bob Rossi wrote: > 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'. > I think my change works in support of this, but there is some complication that I don't understand. In one example that I've got dirname is relative and filename is just the filename. However in another example dirname is empty and filename is a relative path like the ../lib/foo.c example from the docs. This later case works fine all the time (haven't looked at the final test of /mnt/cross/foo.c though), however the first case fails. My change converts this first case into the second case. What I don't understand is why does the symtab sometimes have the path and filename separate and other times have them already concatenated? > 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? Yes this does work, but its quite restrictive. We're now letting GDB dictate what your current working directory is allowed to be. Our application's behaviour depends on the cwd and so I can't always run it from where GDB would feel more comfortable. I believe the dir command exists for this very reason, so I can explain to GDB where it will find the source. Cheers, Craig.