This is the mail archive of the mailing list for the Insight project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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, 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 Branch: MAIN 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?

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]