From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11273 invoked by alias); 6 Oct 2005 23:33: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 11226 invoked by uid 22791); 6 Oct 2005 23:33:47 -0000 Received: from 220-245-201-253.static.tpgi.com.au (HELO universe.preston.net) (220.245.201.253) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 06 Oct 2005 23:33:47 +0000 Received: from norman (norman.preston.net [202.14.10.82]) by universe.preston.net (8.11.6/8.11.6) with ESMTP id j96NW1A00382; Fri, 7 Oct 2005 09:32:18 +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: <20051006130035.GA6184@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> <1128566917.18954.39.camel@norman> <20051006130035.GA6184@white> Content-Type: text/plain Date: Thu, 06 Oct 2005 23:33:00 -0000 Message-Id: <1128641520.18954.63.camel@norman> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-10/txt/msg00056.txt.bz2 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. > 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. Ideally we should have consitent behaviour for the case where the relative path bit is in dirname. Cheers, Craig.