From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7151 invoked by alias); 7 Oct 2005 00:25:33 -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 7142 invoked by uid 22791); 7 Oct 2005 00:25:30 -0000 Received: from eastrmmtao02.cox.net (HELO eastrmmtao02.cox.net) (68.230.240.37) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 07 Oct 2005 00:25:30 +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 <20051007002516.HTXA22723.eastrmmtao02.cox.net@white>; Thu, 6 Oct 2005 20:25:16 -0400 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1ENg38-0001wa-00; Thu, 06 Oct 2005 20:25:22 -0400 Date: Fri, 07 Oct 2005 00:25: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: <20051007002522.GA7444@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> <20051006130035.GA6184@white> <1128641520.18954.63.camel@norman> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1128641520.18954.63.camel@norman> User-Agent: Mutt/1.5.9i X-SW-Source: 2005-10/txt/msg00058.txt.bz2 On Fri, Oct 07, 2005 at 09:32:00AM +1000, Craig Jeffree wrote: > On Thu, 2005-10-06 at 09:00 -0400, Bob Rossi wrote: > > 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. > > I wonder how this works with header files, in my application for some > reason the filename ends up being split into dirname (the relative path > bit) and filename (just the actual filename). However in a little test > case I tried to make to reproduce it I ended up with an empty dirname > and the whole relative path+filename in filename. It's only the former > case that causes problems. Yes, I reproduced the problem with the former. If you have this directory structure: gdb_path/ src/ main.c include/ foo.h and you compile in src/ with 'gcc -g main.cpp -I../include -o main' then you will end up with dirname=../include and filename=foo.h. > > 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? > > Not quite. I'm proposing "If dirname is absolute behave as it does now, > if dirname is relative prepend it to filename and treat dirname as > empty". This gives the new search from your example above to be... > > 1. Look for ../src/foo.c > 2. For each source_path, Look for source_path[i]/../src/foo.c > > I believe this is how it already behaves in all cases where the symtab > contains an empty dirname and a relatively pathed filename. Yes, it probably does behave that way. > Ideally we should have consistent behavior for the case where the relative path bit > is in dirname. Does anyone have any ideas why doing this would cause GDB to not find files it does now? Craig, you should be able to put your patch into source.c:find_and_open_source in the part where it checks for if (dirname != NULL) { ... } instead of appending to the source_path, simply change the filename and leave the source_path alone. Run this through the testsuite, are there any errors? I still have to think more about this to figure out how it effects GDB searching. Anyone have any advice? For instance, I don't know if it's significant to GDB if the dirname is relative and the filename is just the name or if the dirname is empty and the filename is relative. Your suggested changes will make this fact irrelavant. Thanks, Bob Rossi