This is the mail archive of the
mailing list for the Insight project.
RE: Can't find source files
- From: "Dave Korn" <dk at artimi dot com>
- To: "'geneSmith'" <gene dot smith at sea dot siemens dot com>,<insight at sources dot redhat dot com>
- Date: Tue, 12 Oct 2004 16:08:51 +0100
- Subject: RE: Can't find source files
> -----Original Message-----
> From: insight-owner On Behalf Of geneSmith
> Sent: 12 October 2004 15:29
> The 9th Edition of "Debugging with GDB"
Hmm, that's what it also says at the start of my info files:
" This file describes GDB, the GNU symbolic debugger.
This is the Ninth Edition, for GDB Version 6.1.1. "
>on page 61 also states:
My one doesn't have page numbers. Do you have an actual book, with like
ink and pages and paper and everything? Wow!
> "For example, suppose an executable references the file
> and our source path is '/mnt/cross'. The file is first looked up
> literally; if this fails,'/mnt/cross/usr/src/foo-1.0/lib/foo.c' is
> tried; if this fails, '/mnt/cross/foo.c' is
> opened; if this fails, an error message is printed."
Ah, but it's not concatenating two items in the source path, it's
concatenating the filename stored in the debug info inside the file with
each of the source path components one by one. Under no circumstances would
it concatenate two different entries from the source path, which is what you
seemed to be hoping it would do when you put "/cygdrive/d" and
"/usr/home/gene" into the source path and wanted it to look in
> I think this is right after where you quoted.
There's nothing that says that in my copy of gdb.info, but it occurred to
me to look a bit deeper, and I discovered this:
Revision 1.212 / (download) - annotate - [select for diffs] , Fri Jul 30
19:23:54 2004 UTC (2 months, 1 week ago) by eliz
CVS Tags: drow_intercu-merge-20040915
Changes since 1.211: +23 -9 lines
Diff to previous 1.211 (colored)
gdb.texinfo (Source Path): Document the new behavior of
searching for the source files.
I think that probably explains everything.
> It does not explicitly say "concatentate" but that seem like what the
> middle example is, /mnt/cross/usr/src/foo-1.0/lib/foo.c .
Yes, that quite explicitly is concatenation. It also turns out to be
fairly new behaviour. It was added on 30th July this year. And it's only
on HEAD, because the gdb_6_2-branch had already been forked, and nobody's
ported it across.
So, the question is, is your version of gdb built from sources from CVS
more recently than 30th July this year?
If not, then the reason why it doesn't find your sources is because it
doesn't actually implement the newer functionality!
If so, then the reason why it doesn't find your sources must be because of
the source file path contained within the debug info in the executable.
For instance, if, as you say, your source path is made of $cwd and $cdir,
which amounts to "/cygdrive/d" and "/usr/home/gene", and the executable
you're running refers to the file "foo.c", gdb will only search for
"/cygdrive/d/foo.c" and "/usr/home/gene/foo.c". OTOH, if the executable
refers to "/usr/home/gene/foo.c", you would expect gdb to first search for
"/usr/home/gene/foo.c" and not find it, then look for
"/cygdrive/d/usr/home/gene/foo.c" and find it.
So it depends what kind of directory paths are already in the executable.
Use "objdump -g <executable file name>" to take a look.
Can't think of a witty .sigline today....