public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Craig Jeffree <craig.jeffree@preston.net>
To: Bob Rossi <bob@brasko.net>
Cc: gdb@sources.redhat.com
Subject: Re: trouble locating source files through relative paths
Date: Tue, 23 Aug 2005 05:04:00 -0000	[thread overview]
Message-ID: <1124773410.3749.38.camel@norman> (raw)
In-Reply-To: <20050819124329.GA18911@white>

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.

  reply	other threads:[~2005-08-23  5:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-19  7:25 Craig Jeffree
2005-08-19 12:43 ` Bob Rossi
2005-08-23  5:04   ` Craig Jeffree [this message]
2005-08-23  9:20     ` Dave Korn
2005-08-23 11:31     ` Bob Rossi
2005-08-23 11:40       ` Bob Rossi
2005-08-23 14:49         ` Daniel Jacobowitz
2005-08-23 15:24           ` Bob Rossi
2005-08-24  6:55         ` Craig Jeffree
2005-08-24 11:24           ` Bob Rossi
2005-08-25  0:07             ` Craig Jeffree
2005-08-25 13:14               ` Bob Rossi
2005-08-25 23:43                 ` Craig Jeffree
2005-08-26  2:20                   ` Bob Rossi
2005-08-26  3:35                     ` Craig Jeffree

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1124773410.3749.38.camel@norman \
    --to=craig.jeffree@preston.net \
    --cc=bob@brasko.net \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).