From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19002 invoked by alias); 23 Aug 2005 05:04:00 -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 18967 invoked by uid 22791); 23 Aug 2005 05:03:48 -0000 Received: from chfw.preston.net (HELO universe.preston.net) (202.14.89.130) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 23 Aug 2005 05:03:48 +0000 Received: from norman (norman.preston.net [202.14.10.82]) by universe.preston.net (8.11.6/8.11.6) with ESMTP id j7N53Ud09227; Tue, 23 Aug 2005 15:03:32 +1000 Subject: Re: trouble locating source files through relative paths From: Craig Jeffree To: Bob Rossi Cc: gdb@sources.redhat.com In-Reply-To: <20050819124329.GA18911@white> References: <1124436292.3582.64.camel@norman> <20050819124329.GA18911@white> Content-Type: text/plain Date: Tue, 23 Aug 2005 05:04:00 -0000 Message-Id: <1124773410.3749.38.camel@norman> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-08/txt/msg00081.txt.bz2 On Fri, 2005-08-19 at 08:43 -0400, Bob Rossi wrote: > What was the 'dir' command that you issued? What compiler are you using? > Do you know what debug format you are using? (stabs or dwarf)? The dir command that I issued was: (gdb) dir /staff/taam/taam/bin/x86-Linux/nostrip/ Source directories searched: /staff/taam/taam/bin/x86-Linux/nostrip: $cdir:$cwd I'm using gcc 3.2.3 with the default debug format for x86-Linux (dwarf2 I believe). > 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've done this before, so I know that it worked at some point. It should > still work. Looking further through the gdb source code I'm not sure how it would do what the documentation suggests, let me take you through it - hopefully I'm not too long winded. If I attach 'strace' to the running gdb process with the default source search path and watch what it does when I issue the command: "list GeAttribute.H:1" strace will show (among many other things) this: stat64("../../../include/General/GeAttribute.H", 0xbfffeddc) = -1 ENOENT (No such file or directory) stat64("/staff/cjeffree/taam/GeAttribute.H", 0xbfffeddc) = -1 ENOENT (No such file or directory) 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? Or in my understanding of the expected vs. actual behaviour? Is there another way I can drive gdb to get my expected behaviour? Thanks for you help so far. Cheers, Craig.