gdb has problems finding my sources

gdb has problems finding my sources

[Tarjei Knapstad]

I've got a C++ test suite project that includes headers from and links
with static libraries from another project which resides in a different
directory tree (also pure C++). I'm using the current Fedora Core 2
snapshot of gdb (gdb-6.0post-0.20031117.7 from 08-01-2004), but I've got
the same problems with either 5.2 or 5.3.

When debugging this testsuite gdb apparently has problems when I try to
step into (template) functions contained in certain header files. The
headers in question contain only template code which is used and linked
into the testsuite application. gdb just gives me "xxx yyy.h: File or
directory not found" where xxx is a line number and yyy.h is the header
file in question. 

If I add the source directory for yyy.h explicitly from gdb using the
'dir' command it works, but I don't understand why I should have to do
that - it works perfectly with for instance the Boost and STL headers.
The other problems with adding the searchpath explicitly is that I'm
using gdb from within KDevelop where I don't have access to the gdb
commandline, as well as the fact that it's a great nusiance to have to
add the dirs (there are potentially lots) each time I run the debugger. 

I've reproduced this exact same behaviour using gdb from the commandline
so I don't think it's KDevelop's fault.

Is there anyone who could provide me with any pointers wrt. how I can
possibly fix this? Any help getting this sorted would be much
appreciated.

Thanks in advance,
--
Tarjei Knapstad

Re: gdb has problems finding my sources

[Daniel Jacobowitz]

On Wed, Jan 21, 2004 at 03:09:13PM +0100, Tarjei Knapstad wrote:
> I've got a C++ test suite project that includes headers from and links
> with static libraries from another project which resides in a different
> directory tree (also pure C++). I'm using the current Fedora Core 2
> snapshot of gdb (gdb-6.0post-0.20031117.7 from 08-01-2004), but I've got
> the same problems with either 5.2 or 5.3.
> 
> When debugging this testsuite gdb apparently has problems when I try to
> step into (template) functions contained in certain header files. The
> headers in question contain only template code which is used and linked
> into the testsuite application. gdb just gives me "xxx yyy.h: File or
> directory not found" where xxx is a line number and yyy.h is the header
> file in question. 
> 
> If I add the source directory for yyy.h explicitly from gdb using the
> 'dir' command it works, but I don't understand why I should have to do
> that - it works perfectly with for instance the Boost and STL headers.
> The other problems with adding the searchpath explicitly is that I'm
> using gdb from within KDevelop where I don't have access to the gdb
> commandline, as well as the fact that it's a great nusiance to have to
> add the dirs (there are potentially lots) each time I run the debugger. 
> 
> I've reproduced this exact same behaviour using gdb from the commandline
> so I don't think it's KDevelop's fault.
> 
> Is there anyone who could provide me with any pointers wrt. how I can
> possibly fix this? Any help getting this sorted would be much
> appreciated.

If you can provide a small testcase for the problem, we can investigate
some more.  I'm not sure from your description what could be broken.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb has problems finding my sources

[Tarjei Knapstad]

On Wed, 2004-01-21 at 16:12, Daniel Jacobowitz wrote:
> On Wed, Jan 21, 2004 at 03:09:13PM +0100, Tarjei Knapstad wrote:

<snip, OP>

> If you can provide a small testcase for the problem, we can investigate
> some more.  I'm not sure from your description what could be broken.
> 

Thanks, I'll make an effort to do so within the next couple of days.

Cheers,
--
Tarjei Knapstad

Re: gdb has problems finding my sources (now with testcase)

[Tarjei Knapstad]

On Wed, 2004-01-21 at 16:12, Daniel Jacobowitz wrote:
> On Wed, Jan 21, 2004 at 03:09:13PM +0100, Tarjei Knapstad wrote:
> > I've got a C++ test suite project that includes headers from and links
> > with static libraries from another project which resides in a different
> > directory tree (also pure C++). I'm using the current Fedora Core 2
> > snapshot of gdb (gdb-6.0post-0.20031117.7 from 08-01-2004), but I've got
> > the same problems with either 5.2 or 5.3.
> > 
> > When debugging this testsuite gdb apparently has problems when I try to
> > step into (template) functions contained in certain header files. The
> > headers in question contain only template code which is used and linked
> > into the testsuite application. gdb just gives me "xxx yyy.h: File or
> > directory not found" where xxx is a line number and yyy.h is the header
> > file in question. 
> > 
> > If I add the source directory for yyy.h explicitly from gdb using the
> > 'dir' command it works, but I don't understand why I should have to do
> > that - it works perfectly with for instance the Boost and STL headers.
> > The other problems with adding the searchpath explicitly is that I'm
> > using gdb from within KDevelop where I don't have access to the gdb
> > commandline, as well as the fact that it's a great nusiance to have to
> > add the dirs (there are potentially lots) each time I run the debugger. 
> > 
> > I've reproduced this exact same behaviour using gdb from the commandline
> > so I don't think it's KDevelop's fault.
> > 
> > Is there anyone who could provide me with any pointers wrt. how I can
> > possibly fix this? Any help getting this sorted would be much
> > appreciated.
> 
> If you can provide a small testcase for the problem, we can investigate
> some more.  I'm not sure from your description what could be broken.
> 

OK, I have just created a tiny KDevelop project, autoconf and all, which
reproduces the problem exactly. The roughly 360kB tarball can be
downloaded from:
   
http://www.chemcon.no/files/gdbtest.tar.bz2

I made a KDevelop project to reproduce all compiler arguments etc.
exactly - sorry about the size.

Run configure in the gdbtest-0.1/ subdirectory with these arguments:

   ./configure --with-extra-includes=../../../ --enable-debug=full

and then just run make. Load up the resulting executable in gdb and
issue

   b Test2.cpp:9

When the execution breaks and I issue a step command ('s') I get the
following:


Starting program: /home/tarjeik/temp/gdbtest-0.1/gdbtest/gdbtest 

Breakpoint 1, Test2::f() (this=0xbffff3c7) at Test2.cpp:9
9           t.f(); // Set breakpoint here
(gdb) s
Test<int>::f() (this=0xbffff3a7) at Test.h:9
9       Test.h: No such file or directory.
        in Test.h
 

Here's the compiler etc. I use:

    gcc-3.3.2-1
    binutils-2.14.90.0.6-3
    gdb-6.0post-0.20031117.7

I hope this helps somewhat - if not let me know if there's anything else
I can provide to track this down. 

Cheers,
--
Tarjei Knapstad

Re: gdb has problems finding my sources (now with testcase)

[Tarjei Knapstad]

On Wed, 2004-01-21 at 17:53, Tarjei Knapstad wrote:
> On Wed, 2004-01-21 at 16:12, Daniel Jacobowitz wrote:
> > On Wed, Jan 21, 2004 at 03:09:13PM +0100, Tarjei Knapstad wrote:
> 

<snip>

> OK, I have just created a tiny KDevelop project, autoconf and all, which
> reproduces the problem exactly. The roughly 360kB tarball can be
> downloaded from:
>    
> http://www.chemcon.no/files/gdbtest.tar.bz2
> 
> I made a KDevelop project to reproduce all compiler arguments etc.
> exactly - sorry about the size.
> 
> Run configure in the gdbtest-0.1/ subdirectory with these arguments:
> 
>    ./configure --with-extra-includes=../../../ --enable-debug=full
> 

I've done some more testing, and the relative include path seems to be
the problem. If I use --with-extra-includes=/full/path/to/header instead
it works flawlessly. I noticed the new ongoing thread about absolute
source file paths which may be related to this. 

Is there any argument I can give gdb that will make it accept relative
paths? The reason for using relative paths is because this is usually
set from within KDevelop, and the KDevelop project file lives in CVS. I
would like to avoid having /home/joesixpack paths in this file as it
would mean every developer would have to change this manually at every
update.

<snip>

Cheers,
--
Tarjei Knapstad