This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: Can't find source files
Dave Korn wrote, On 10/12/2004 11:08 AM:
-----Original Message-----
From: insight-owner On Behalf Of geneSmith
Sent: 12 October 2004 15:29
Dave,
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
'/usr/src/foo-1.0/lib/foo.c',
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
"/cygdrive/d/usr/home/gene".
Right, I want it to cat /cygdrive/d (set with dir) to /home/gene/source
(obtain from the runtime file). Maybe I didn't explain this clearly.
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:
-----------------------<snip!>-----------------------
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/doc/gdb.texinfo?cvsroot
=src
Revision 1.212 / (download) - annotate - [select for diffs] , Fri Jul 30
19:23:54 2004 UTC (2 months, 1 week ago) by eliz
Branch: MAIN
CVS Tags: drow_intercu-merge-20040915
Changes since 1.211: +23 -9 lines
Diff to previous 1.211 (colored)
[........snip!........]
gdb.texinfo (Source Path): Document the new behavior of
searching for the source files.
-----------------------<snip!>-----------------------
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?
What I have was built by a 3rd party (macraigor) to support their
emulator. They tell me the source was not modified in any way. It is
from gdb 6.1 according to help|about.
If not, then the reason why it doesn't find your sources is because it
doesn't actually implement the newer functionality!
It usually works as advertised. Just the case in my original post seems
not to work (where the path from the runtime file starts with /home/gene).
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.
Yes, this is my case except the exe refers to /home/gene/source but that
is not a big deal. FWIW, my $cwd is somewhere else entirely. My problem
is that the project (RTEMS) has a totally disjoint build vs. source tree
so that the exe's contain really long references back to the source
containing many ../'s with varying levels. Getting gdb to see the source
you have to set dir like this is .gdbinit:
dir
/cygdrive/f/xfer/4.6.1-rtems/tools/build-rtems/powerpc-rtems/c/myproj/lib/libbsp/powerpc/cp4431adv/startup
(Plus other dir's for various source levels, quite complex)
But if I move "build-rtems" directory up to root on the linux box and
build there, I eliminate all the ../'s from the exe and all I would need
to set in .gdbinit is
dir /cygdrive/f
which would be all I need since in exe all source paths rooted at
/home/gene/... with no complex backtracking. But this simple case does
not seem to work.
So it depends what kind of directory paths are already in the executable.
Use "objdump -g <executable file name>" to take a look.
When I do this it always says "no recognizable debug information." But
the source paths and debug information and source statements can be seen
in the file with objdump -Sx <exe file> and with vi. Compiling with -g
and not stripping.
--
Lit up like Levy's