Re: trouble locating source files through relative paths

[Craig Jeffree <craig dot jeffree at preston dot net>]

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.