From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20368 invoked by alias); 6 Oct 2005 13:00:50 -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 20329 invoked by uid 22791); 6 Oct 2005 13:00:44 -0000 Received: from eastrmmtao03.cox.net (HELO eastrmmtao03.cox.net) (68.230.240.36) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 06 Oct 2005 13:00:44 +0000 Received: from white ([68.9.64.121]) by eastrmmtao03.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051006130029.UKLY2767.eastrmmtao03.cox.net@white>; Thu, 6 Oct 2005 09:00:29 -0400 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1ENVMS-0001dC-00; Thu, 06 Oct 2005 09:00:36 -0400 Date: Thu, 06 Oct 2005 13:00: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: <20051006130035.GA6184@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> <20051006021548.GA5232@white> <1128566917.18954.39.camel@norman> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1128566917.18954.39.camel@norman> User-Agent: Mutt/1.5.9i X-SW-Source: 2005-10/txt/msg00055.txt.bz2 On Thu, Oct 06, 2005 at 12:48:37PM +1000, Craig Jeffree wrote: > 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? Yes, this makes sense. Basically, the dirname is simply added to the source path, nothing else is done with it. AFAIK, the symtab will have the filename be what you gave to it on the compile line. For example, 'gcc -g ../main.c -o main' will give a filename of '../main.c', and if you do 'gcc -g main.c -o main', it will give a filename of 'main.c'. However, I'm not an expert on this. So I think GDB is doing what it says it should do in the documentation. Basically, if you have a filename of '../lib/foo.c', GDB tries that first. Then for each source path it does 'source_path[i]/../lib/foo.c'. Finally, for some strange reason it does 'source_path[i]/foo.c'. All of this has nothing to do with the dirname, except for the fact that the dirname get's put into the source path. If you have includes like '../lib/foo.c' which are relative to where the executable was, then when you run the 'dir exe_location', then GDB will be able to find the file. However, if you have non-relative paths like foo.c, then GDB will not be able to find it. > > 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. Yes, you are correct. It would be nice to have GDB start from anywhere, and allow it to find your files. I think we are going to have to make a change to GDB, which alters the way it looks for files. For instance, if you want to start using the dirname, do we make those checks before the others, or after? Here's the current order looking for foo.c with dirname of '../src' 1. Look for foo.c 2. For each source_path, Look for source_path[i]/foo.c This case will search for 'foo.c' and '../src/foo.c'. The new search would be something like, 1. Look for foo.c 2. For each source_path, Look for source_path[i]/foo.c 3. Look for ../src/foo.c /* Not needed */ 4. For each source_path, Look for source_path[i]/../src/foo.c This case will search for 'foo.c', '../src/foo.c', '../src/foo.c' and source_path[i]/../src/foo.c. The 3 case isn't needed, since it will be searched for in the second case. Is this what you are suggesting to change? Thanks, Bob Rossi