trouble locating source files through relative paths

trouble locating source files through relative paths

[Craig Jeffree]

Hi,

I've been having trouble getting GDB (v6.3 build myself from source on
RHEL4) to locate the source files associated with the binary I'm
debugging.  The binary refers to some source files using relative paths
say for example:

../../include/General/GeString.H

This file exists but the path from which the relative path should start
differs now because the binary has been moved.

I've added the correct starting path to my source search path using the
'dir' command and expect GDB to find the file now as described in the
GDB manual here:
http://sources.redhat.com/gdb/download/onlinedocs/gdb_8.html#SEC53

However an strace of GDB shows that it only looks for GeString.H in the
newly specified search path directory and doesn't ever try using the
search path as a base for the relative directories.

If I ignore the relative path and set the search path to the full path
to this file it works, however the application has hundreds of files,
some of which have conflicting names if the directory path isn't
included.  

How can I get GDB to use the search path as a base for relative paths
specified in the debug info rather than only looking directly in the
search path dirs?

Cheers,
Craig.

Re: trouble locating source files through relative paths

[Bob Rossi]

> I've been having trouble getting GDB (v6.3 build myself from source on
> RHEL4) to locate the source files associated with the binary I'm
> debugging.  The binary refers to some source files using relative paths
> say for example:
> 
> ../../include/General/GeString.H
> 
> This file exists but the path from which the relative path should start
> differs now because the binary has been moved.
> 
> I've added the correct starting path to my source search path using the
> 'dir' command and expect GDB to find the file now as described in the
> GDB manual here:
> http://sources.redhat.com/gdb/download/onlinedocs/gdb_8.html#SEC53

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)?

Have you tried using the cdir command? That might work.

> However an strace of GDB shows that it only looks for GeString.H in the
> newly specified search path directory and doesn't ever try using the
> search path as a base for the relative directories.
> 
> If I ignore the relative path and set the search path to the full path
> to this file it works, however the application has hundreds of files,
> some of which have conflicting names if the directory path isn't
> included.  
> 
> How can I get GDB to use the search path as a base for relative paths
> specified in the debug info rather than only looking directly in the
> search path dirs?

I've done this before, so I know that it worked at some point. It should
still work.

Bob Rossi

Re: trouble locating source files through relative paths

[Craig Jeffree]

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.

RE: trouble locating source files through relative paths

[Dave Korn]

----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....

Re: trouble locating source files through relative paths

[Bob Rossi]

On Tue, Aug 23, 2005 at 03:03:29PM +1000, Craig Jeffree wrote:
> 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).

Is this problem reproducable in a small example?

Thanks,
Bob Rossi

Re: trouble locating source files through relative paths

[Bob Rossi]

On Tue, Aug 23, 2005 at 07:31:38AM -0400, Bob Rossi wrote:
> On Tue, Aug 23, 2005 at 03:03:29PM +1000, Craig Jeffree wrote:
> > 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).
> 
> Is this problem reproducable in a small example?

Geez, actually, I did just reproduce the problem. It seems that the only
current solution to get it to work is to do as you said, put the path to
where the include file is, not to where the relative path to it is.

I'll look into this.

Thanks,
Bob Rossi

Re: trouble locating source files through relative paths

[Daniel Jacobowitz]

On Tue, Aug 23, 2005 at 07:40:28AM -0400, Bob Rossi wrote:
> On Tue, Aug 23, 2005 at 07:31:38AM -0400, Bob Rossi wrote:
> > On Tue, Aug 23, 2005 at 03:03:29PM +1000, Craig Jeffree wrote:
> > > 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).
> > 
> > Is this problem reproducable in a small example?
> 
> Geez, actually, I did just reproduce the problem. It seems that the only
> current solution to get it to work is to do as you said, put the path to
> where the include file is, not to where the relative path to it is.
> 
> I'll look into this.

Great!  Yeah, I've seen this one before - I posted a (less thorough!)
analysis of it back when openp.exp was posted.  I would _love_ to see
this fixed.  IIRC, you can also trigger it by using -I../include and
trying to list code in a header file; I had a test case in the
gdb-patches archives somewhere but never had time to track it down.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: trouble locating source files through relative paths

[Bob Rossi]

On Tue, Aug 23, 2005 at 10:49:11AM -0400, Daniel Jacobowitz wrote:
> On Tue, Aug 23, 2005 at 07:40:28AM -0400, Bob Rossi wrote:
> > On Tue, Aug 23, 2005 at 07:31:38AM -0400, Bob Rossi wrote:
> > > On Tue, Aug 23, 2005 at 03:03:29PM +1000, Craig Jeffree wrote:
> > > > 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).
> > > 
> > > Is this problem reproducable in a small example?
> > 
> > Geez, actually, I did just reproduce the problem. It seems that the only
> > current solution to get it to work is to do as you said, put the path to
> > where the include file is, not to where the relative path to it is.
> > 
> > I'll look into this.
> 
> Great!  Yeah, I've seen this one before - I posted a (less thorough!)
> analysis of it back when openp.exp was posted.  I would _love_ to see
> this fixed.  IIRC, you can also trigger it by using -I../include and
> trying to list code in a header file; I had a test case in the
> gdb-patches archives somewhere but never had time to track it down.

Exactly, this is how I reproduced it. Trying to open code in a header
via ../inc. The funny thing is, 'info sources' finds the file after the
dir command is added. This tells me that psymtab_to_fullname is working.

What's not working is the list command. That could be the problem.

Bob Rossi

Re: trouble locating source files through relative paths

[Craig Jeffree]

On Tue, 2005-08-23 at 07:40 -0400, Bob Rossi wrote:
> I'll look into this.

It looks like find_and_open_source() could be modified to check if
dirname is relative and if so call openp with dirname prepended to
filename instead of modifying the search path.

I think this is what Dave Korn suggested earlier, except he proposes
identifying the relative link before the call to find_and_open_source
and avoiding the split at that point.  However, this might result in
checks occuring in multiple places - I haven't looked for this.

I'm not familiar with the gdb source so I'm not sure which solution will
be more appropriate.  Putting the fix in find_and_open_source() would be
more self contained, however this might affect other clients of
find_and_open_source() in ways I haven't considered.

Cheers,
Craig.

Re: trouble locating source files through relative paths

[Bob Rossi]

On Wed, Aug 24, 2005 at 04:53:57PM +1000, Craig Jeffree wrote:
> On Tue, 2005-08-23 at 07:40 -0400, Bob Rossi wrote:
> > I'll look into this.
> 
> It looks like find_and_open_source() could be modified to check if
> dirname is relative and if so call openp with dirname prepended to
> filename instead of modifying the search path.
> 
> I think this is what Dave Korn suggested earlier, except he proposes
> identifying the relative link before the call to find_and_open_source
> and avoiding the split at that point.  However, this might result in
> checks occuring in multiple places - I haven't looked for this.
> 
> I'm not familiar with the gdb source so I'm not sure which solution will
> be more appropriate.  Putting the fix in find_and_open_source() would be
> more self contained, however this might affect other clients of
> find_and_open_source() in ways I haven't considered.

Well, I haven't had enough time to investigate this more, however, I did
find some odd results with the example I came up with. For example, if
I do 'info sources' before the dir command is applied, GDB spits out the
relative path. However, if I do the dir command, and then do 'info
sources', then GDB spits out the absolute path.

Once GDB has the absolute path, if I then do 'list uut.h:1', GDB can
still not find the file. If I do 'list ../include/uut.h:1',
then I get an Internal GDB error. Do you get these same results?

If so, find_and_open_source is finding the fullname, even though things
are still not working properly. Hopefully I'll have more time to look
into this today.

Thanks,
Bob Rossi

Re: trouble locating source files through relative paths

[Craig Jeffree]

On Wed, 2005-08-24 at 07:24 -0400, Bob Rossi wrote:
> Well, I haven't had enough time to investigate this more, however, I did
> find some odd results with the example I came up with. For example, if
> I do 'info sources' before the dir command is applied, GDB spits out the
> relative path. However, if I do the dir command, and then do 'info
> sources', then GDB spits out the absolute path.

Both before and after I do the 'dir' command 'info sources' spits out
the filename with no path at all.

> 
> Once GDB has the absolute path, if I then do 'list uut.h:1', GDB can
> still not find the file. If I do 'list ../include/uut.h:1',
> then I get an Internal GDB error. Do you get these same results?

When I do 'list GeAttribute.H:1' in my application GDB fails to find the
file after trying 'GeAttribute.H' in the directory I specified with
'dir' and my cwd.  It also tries
'../../../include/General/GeAttribute.H'.  I can't say I know where it
figures out this relative path from because 'info sources' doesn't
mention it, however that path is correct when taken from the location of
the binary (the path I gave to 'dir').

If I try 'list ../../../include/General/GeAttribute.H:1' it says:
'No source file named ../../../include/General/GeAttribute.H.'

The strace during 'list ../../../include/General/GeAttribute.H:1'
indicates that no attempt is made to look for this file.  GDB must
determine this by looking at the list of source files gathered from the
binary.
 
Cheers,
Craig.

Re: trouble locating source files through relative paths

[Bob Rossi]

On Thu, Aug 25, 2005 at 10:07:12AM +1000, Craig Jeffree wrote:
> On Wed, 2005-08-24 at 07:24 -0400, Bob Rossi wrote:
> > Well, I haven't had enough time to investigate this more, however, I did
> > find some odd results with the example I came up with. For example, if
> > I do 'info sources' before the dir command is applied, GDB spits out the
> > relative path. However, if I do the dir command, and then do 'info
> > sources', then GDB spits out the absolute path.
> 
> Both before and after I do the 'dir' command 'info sources' spits out
> the filename with no path at all.
> 
> > 
> > Once GDB has the absolute path, if I then do 'list uut.h:1', GDB can
> > still not find the file. If I do 'list ../include/uut.h:1',
> > then I get an Internal GDB error. Do you get these same results?
> 
> When I do 'list GeAttribute.H:1' in my application GDB fails to find the
> file after trying 'GeAttribute.H' in the directory I specified with
> 'dir' and my cwd.  It also tries
> '../../../include/General/GeAttribute.H'.  I can't say I know where it
> figures out this relative path from because 'info sources' doesn't
> mention it, however that path is correct when taken from the location of
> the binary (the path I gave to 'dir').
> 
> If I try 'list ../../../include/General/GeAttribute.H:1' it says:
> 'No source file named ../../../include/General/GeAttribute.H.'

Hi Craig,

Thanks for all the explaining. I have yet another question. Does
GeAttribute.H also have a counterpart GeAttribute.cpp? If so, is that
file found by GDB before or after the dir command? I appreciate the
response's because the examples I reproduce are slightly different then
what you are seeing, although it might be enough to prove the point.

Thanks,
Bob Rossi

Re: trouble locating source files through relative paths

[Craig Jeffree]

On Thu, 2005-08-25 at 07:11 -0400, Bob Rossi wrote:
> Thanks for all the explaining. I have yet another question. Does
> GeAttribute.H also have a counterpart GeAttribute.cpp? If so, is that
> file found by GDB before or after the dir command? I appreciate the
> response's because the examples I reproduce are slightly different then
> what you are seeing, although it might be enough to prove the point.

Thank-you for looking into this!  GeAttribute.H is just a header, there
is no corresponding .cpp file.

Re: trouble locating source files through relative paths

[Bob Rossi]

On Fri, Aug 26, 2005 at 09:43:00AM +1000, Craig Jeffree wrote:
> On Thu, 2005-08-25 at 07:11 -0400, Bob Rossi wrote:
> > Thanks for all the explaining. I have yet another question. Does
> > GeAttribute.H also have a counterpart GeAttribute.cpp? If so, is that
> > file found by GDB before or after the dir command? I appreciate the
> > response's because the examples I reproduce are slightly different then
> > what you are seeing, although it might be enough to prove the point.
> 
> Thank-you for looking into this!  GeAttribute.H is just a header, there
> is no corresponding .cpp file.

OK, thanks. Is there any .cpp files that are in the relative directory? I
want to know if GDB can find the .cpp files but not the .H files. So, do
'info sources' before the dir command and check to see if the .cpp files
from the relative directory have an absolute path to them. If not, do the
dir command, and then see. Thanks.

Bob Rossi

Re: trouble locating source files through relative paths

[Craig Jeffree]

On Thu, 2005-08-25 at 22:20 -0400, Bob Rossi wrote:
> OK, thanks. Is there any .cpp files that are in the relative directory? I
> want to know if GDB can find the .cpp files but not the .H files. So, do
> 'info sources' before the dir command and check to see if the .cpp files
> from the relative directory have an absolute path to them. If not, do the
> dir command, and then see. Thanks.

Unfortunately no.  Our build system "installs" header files into a
common include directory and this include directory is specified as a
relative path in the -I option to g++.  The actual compilation units are
always specified to g++ simply by filename as they are always in the
current working directory since make changes to that directory.

Cheers,
Craig.