This is the mail archive of the insight@sources.redhat.com 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


Hopefully this isn't too off subject ...

We use a symbolic link to solve the problem that Gene is experiencing

For example (from cygwin):

ln -s /cygdrive/d/home /home

Now the sources will appear at the same location in the cygwin file 
system.  

Of course if you already have a directory named "home" in your 
cygwin root, you might need something like:

ln -s /cygdrive/d/home/gene /home/gene

In our application, this is more convenient than adding GDB paths.

Hope this helps,
Derek


-----Original Message-----
From: insight-owner@sources.redhat.com
[mailto:insight-owner@sources.redhat.com] On Behalf Of Dave Korn
Sent: Tuesday, October 12, 2004 11:09 AM
To: 'geneSmith'; insight@sources.redhat.com
Subject: RE: Can't find source files


> -----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".

> 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?

  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.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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