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 12:42 PM:
-----Original Message-----
From: insight-owner On Behalf Of geneSmith
Sent: 12 October 2004 17:20
<snip>
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:
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.
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
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.
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.,
powerpc-rtems-objdump).
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.
-gene
--
Lit up like Levy's