From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10919 invoked by alias); 23 Aug 2005 09:20:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10901 invoked by uid 22791); 23 Aug 2005 09:20:34 -0000 Received: from host217-40-213-68.in-addr.btopenworld.com (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 23 Aug 2005 09:20:34 +0000 Received: from mace ([192.168.1.25]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Aug 2005 10:20:32 +0100 From: "Dave Korn" To: "'Craig Jeffree'" , "'Bob Rossi'" Cc: Subject: RE: trouble locating source files through relative paths Date: Tue, 23 Aug 2005 09:20:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <1124773410.3749.38.camel@norman> Message-ID: X-SW-Source: 2005-08/txt/msg00085.txt.bz2 ----Original Message---- >From: Craig Jeffree >Sent: 23 August 2005 06:03 >> Have you tried using the cdir command? That might work. > > (gdb) help cdir > Undefined command: "cdir". Try "help". > > What's cdir? What version of gdb is it available in? I think he's probably just referring to 'cd'. > That is what I would expect because the binary is not in the current > working directory. Since the path shown in the stat64 (above) for > GeAttribute.H is the correct relative path compared to the binary > location I expect that I should be able to specify the binary's location > using dir: > > dir /staff/taam/taam/bin/x86-Linux/nostrip/ > > and then see gdb search with this as one of the starting points for the > relative path to GeAttribute.H. However strace now shows the following: > > stat64("/staff/taam/taam/bin/x86-Linux/nostrip/GeAttribute.H", > 0xbfffed8c) = -1 ENOENT (No such file or directory) > stat64("../../../include/General/GeAttribute.H", 0xbfffed8c) = -1 ENOENT > (No such file or directory) > stat64("/staff/cjeffree/taam/GeAttribute.H", 0xbfffed8c) = -1 ENOENT (No > such file or directory) > > > So as you can see the newly specified path is now searched, but not with > the full relative path specified in the debug symbols added to it. > Instead gdb strips off the path and just adds the filename. I would > expect to see a stat64 call looking for "/staff/taam/taam/bin/x86- > Linux/nostrip/../../../include/General/GeAttribute.H". At least that's > what the gdb documentation promises. > I then looked inside the function find_and_open_source() in gdb/source.c > at the first call to openp. Stepping through this code in gdb you get > to see that find_and_open_source() is given char > *filename="GeAttribute.H" and char *dirname="../../../include/General/" > separately. 'dirname' is then added to the source search path in place > of $cdir, so it now looks like this: "/staff/taam/taam/bin/x86- > Linux/nostrip:../../../include/General:$cwd". The call to openp would > work if 'dirname' was not separated from 'filename' and added to > 'path'. > > Is this a bug in gdb? I believe you have identified a real bug. I recall someone having a problem getting directory concatenation to work a while ago, and it looks to me like you've identified the problem. The solution needs a bit of thinking about; it may suffice to notice when we have a relative path, and in those cases try calling find_and_open_source (fullpath, NULL or "" as appropriate) before splitting it and trying again if the first attempt fails, but I haven't looked at the source yet. cheers, DaveK -- Can't think of a witty .sigline today....