This is the mail archive of the
mailing list for the Insight project.
Re: Can't find source files
Dave Korn wrote, On 10/12/2004 12:42 PM:
From: insight-owner On Behalf Of geneSmith
Sent: 12 October 2004 17:20
You confused me by referring to $cdir, which i didn't think was the same
thing as the path embedded in the runtime file (else what would be the
point in concatenating it to itself?). IIUIC, $cdir is just a user-level
convenience variable that you can set however suits you.
Page 62 of the gdb manual states"
"You can use the string ‘$cdir’ to refer to the compilation directory
(if one is recorded)..."
which I took to mean the src path embedded in the runtime file for the
current function. The only place I see it refererenced is in the
"directory" path which defaults to "$cdir:$cwd" which implies that the
literal path from the r.t. file is tried first...maybe.
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.
Well, the new source path features are only in mainline (CVS), not in
either the 6.1 nor the 6.2 release branch. Seems like they gave you
documentation from a more up-to-date version of gdb than the actual binary
they gave you!
The gdb manual I was referring I got directly from the fsf site. There
was no indication it describes unreleased features.
you have to set dir like this is .gdbinit:
(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
to set in .gdbinit is
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.
Well, you may _very_ well be able to work around it with a mount point or
symlink or two.
A the symlink method worked. m/p would work too I am sure.
So it depends what kind of directory paths are already in
Use "objdump -g <executable file name>" to take a look.
When I do this it always says "no recognizable debug
the source paths and debug information and source statements
can be seen
in the file with objdump -Sx <exe file> and with vi.
Ummm..... you do have to use the same kind of cross objdump as the cross
compiler and cross debugger, you know..... [guess it is getting late!]
Right, can't just use the pc native objdump (using e.g.,
It looks like in gdb 6.1 the path "concatentate" feature sort of works
but may have bugs for some cases. Thanks for your help in looking at this.
Lit up like Levy's