Can't find source files

Can't find source files

[geneSmith]

If you set directory to:

/cygdrive/d

and your $cdir is /home/gene/source

where d is a samba drive mapped to /

Is there a reason why insight/gdb would not find the files at

/cygdrive/d/home/gene/source ?
-- 
Lit up like Levy's

RE: Can't find source files

[Dave Korn]

> -----Original Message-----
> From: insight-owner On Behalf Of geneSmith
> Sent: 11 October 2004 23:26

> If you set directory to:
> 
> /cygdrive/d
> 
> and your $cdir is /home/gene/source
> 
> where d is a samba drive mapped to /
> 
> Is there a reason why insight/gdb would not find the files at
> 
> /cygdrive/d/home/gene/source ?

  ? I can't see anything in the gdb docs that suggests it would concatenate
$cdir to $cwd.  Where do you get that from ?



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

Re: Can't find source files

[geneSmith]

Dave Korn wrote, On 10/12/2004 5:04 AM:

>>-----Original Message-----
>>From: insight-owner On Behalf Of geneSmith
>>Sent: 11 October 2004 23:26
> 
> 
>>If you set directory to:
>>
>>/cygdrive/d
>>
>>and your $cdir is /home/gene/source
>>
>>where d is a samba drive mapped to /
>>
>>Is there a reason why insight/gdb would not find the files at
>>
>>/cygdrive/d/home/gene/source ?
> 
> 
>   ? I can't see anything in the gdb docs that suggests it would concatenate
> $cdir to $cwd.  Where do you get that from ?
>  
>     cheers, 
>       DaveK

What I am implying is that gdb concatentates the paths specified by 
"directory" with the path to the source file contained in the object 
file as described in Debugging with GDB section 7.4, Specifying source 
directories.

My runtime object files contains paths like /home/gene/source and I have 
set directory in gdb to /cygdrive/d. I am running gdb on cygwin and the 
target files are on a linux box. From windows (cygwin) I can see my 
linux files at /cygdrive/d/home/gene/source but gdb (insight) does not 
display the source. I compiled with -g and am not stripping debug info. 
With other directory and $cdir setting I can see source in insight but 
not wiht this particular setup.

(Maybe I dont' completely know the meaining of $cdir?)

-gene

-- 
Lit up like Levy's

RE: Can't find source files

[Dave Korn]

> -----Original Message-----
> From: insight-owner On Behalf Of geneSmith
> Sent: 12 October 2004 14:31

> Dave Korn wrote, On 10/12/2004 5:04 AM:
> 
> >>-----Original Message-----
> >>From: insight-owner On Behalf Of geneSmith
> >>Sent: 11 October 2004 23:26

> >>If you set directory to:
> >>
> >>/cygdrive/d
> >>
> >>and your $cdir is /home/gene/source
> >>
> >>where d is a samba drive mapped to /
> >>
> >>Is there a reason why insight/gdb would not find the files at
> >>
> >>/cygdrive/d/home/gene/source ?

> >   ? I can't see anything in the gdb docs that suggests it 
> would concatenate $cdir to $cwd.  Where do you get that from ?

> What I am implying is that gdb concatentates the paths specified by 
> "directory" with the path to the source file contained in the object 
> file as described in Debugging with GDB section 7.4, 
> Specifying source directories.

  That's the same bit I read.  Where do you see the word 'concatenate' in
that?

> (Maybe I dont' completely know the meaining of $cdir?)

  I think you're making a false assumption about how path searching works.
Look:

"   When you start GDB, its source path includes only `cdir' and `cwd',
in that order.  To add other directories, use the `directory' command. "

  So, in your case, the source path will include "/home/gene/source" ($cdir,
the compilation dir) and "/cygdrive/d", your current directry ($cwd).  Now
read the bit about how the path search operates:

"  GDB has a list of directories to search for
source files; this is called the "source path".  Each time GDB wants a
source file, it tries all the directories in the list, in the order
they are present in the list, until it finds a file with the desired
name.  "

  So, first gdb looks for your source file in "/home/gene/source", then it
looks in "/cygdrive/d".  Neither of those are the path to your source file,
so it doesn't find it.  At no time does it start concatenating the different
directories in the source path.  It won't look in
/cygdrive/d/home/gene/source.  It won't look in /home/gene/source/cygdrive/d
either, which is what you're suggesting it should do, but is more obviously
wrong....!

  This is all just the same as how $PATH works in your shell.  If you have

PATH=/bin:/usr/bin

you wouldn't expect it to find executables in /bin/usr/bin, would you?

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

Re: Can't find source files

[geneSmith]

Dave Korn wrote, On 10/12/2004 10:10 AM:
>>-----Original Message-----
>>From: insight-owner On Behalf Of geneSmith
>>Sent: 12 October 2004 14:31
> 
> 
>>Dave Korn wrote, On 10/12/2004 5:04 AM:
>>
>>
>>>>-----Original Message-----
>>>>From: insight-owner On Behalf Of geneSmith
>>>>Sent: 11 October 2004 23:26
> 
> 
>>>>If you set directory to:
>>>>
>>>>/cygdrive/d
>>>>
>>>>and your $cdir is /home/gene/source
>>>>
>>>>where d is a samba drive mapped to /
>>>>
>>>>Is there a reason why insight/gdb would not find the files at
>>>>
>>>>/cygdrive/d/home/gene/source ?
> 
> 
>>>  ? I can't see anything in the gdb docs that suggests it 
>>
>>would concatenate $cdir to $cwd.  Where do you get that from ?
> 
> 
>>What I am implying is that gdb concatentates the paths specified by 
>>"directory" with the path to the source file contained in the object 
>>file as described in Debugging with GDB section 7.4, 
>>Specifying source directories.
> 
> 
>   That's the same bit I read.  Where do you see the word 'concatenate' in
> that?
> 
> 
>>(Maybe I dont' completely know the meaining of $cdir?)
> 
> 
>   I think you're making a false assumption about how path searching works.
> Look:
> 
> "   When you start GDB, its source path includes only `cdir' and `cwd',
> in that order.  To add other directories, use the `directory' command. "
> 
>   So, in your case, the source path will include "/home/gene/source" ($cdir,
> the compilation dir) and "/cygdrive/d", your current directry ($cwd).  Now
> read the bit about how the path search operates:
> 
> "  GDB has a list of directories to search for
> source files; this is called the "source path".  Each time GDB wants a
> source file, it tries all the directories in the list, in the order
> they are present in the list, until it finds a file with the desired
> name.  "
> 
>   So, first gdb looks for your source file in "/home/gene/source", then it
> looks in "/cygdrive/d".  Neither of those are the path to your source file,
> so it doesn't find it.  At no time does it start concatenating the different
> directories in the source path.  It won't look in
> /cygdrive/d/home/gene/source.  It won't look in /home/gene/source/cygdrive/d
> either, which is what you're suggesting it should do, but is more obviously
> wrong....!
> 
>   This is all just the same as how $PATH works in your shell.  If you have
> 
> PATH=/bin:/usr/bin
> 
> you wouldn't expect it to find executables in /bin/usr/bin, would you?
> 
>     cheers, 
>       DaveK

Dave,

The 9th Edition of "Debugging with GDB" on page 61 also states:

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

I think this is right after where you quoted. I have seen this work in 
some cases but not for the one I mention (or possibly it's still a user 
error).

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

-- 
Lit up like Levy's

RE: Can't find source files

[Dave Korn]

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

Re: Can't find source files

[geneSmith]

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

RE: Can't find source files

[Dave Korn]

> -----Original Message-----
> From: insight-owner On Behalf Of geneSmith
> Sent: 12 October 2004 17:20

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

  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.

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

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

> >   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!]


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

Re: Can't find source files

[geneSmith]

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

RE: Can't find source files

[Dave Korn]

> -----Original Message-----
> From: insight-owner On Behalf Of geneSmith
> Sent: 13 October 2004 20:09

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

  Yeah, I'm not really sure; that's the only mention of it in the docs and
it's a bit ambiguous.  FWIW I couldn't get a local copy of gdb to place
anything useful in $cdir automatically, even when debugging an application
which it was having no problem finding source locations for.  So I dunno if
there's a bug that means cdir should be automatically set but isn't, or if
that's a misinterpretation of the manual.  It could do with a little
clarification on what a compilation directory is, and where and how
precisely one might be recorded. 

  Ah, ok, I got it.  I've looked through the source.  $cdir is not a real
convenience variable, that's why I wasn't seeing anything from "show conve".
It's a fake that is only substituted in at the very last moment.  The
compilation dir in question is that recorded in the symtab for which the
source is being looked up.

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

  Do you mean http://sources.redhat.com/gdb/documentation/?  It does say 

"Online GDB manuals
Documentation generated from the current sources are available online: "

which implies that the documentation is kept up-to-date with development
work on the sources.  They also keep a version for the last release there as
well.

> A the symlink method worked. m/p would work too I am sure.

  Excellent, at least you can get on with debugging your code instead of
debugging the debugger!

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

  If you're still curious, take a look at the output from "maint show
symtab".  The "dirname" fields show you the actual paths that are recorded
in the symtabs and that are the potential values to be substituted for $cdir
in the source path.

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

Re: Can't find source files

[geneSmith]

Dickinson, Derek wrote, On 10/12/2004 11:38 AM:

> 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

Yeah, already have "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

Alright! This works!   Thanks.
Seeing source I never saw before.
-gene

> 
> In our application, this is more convenient than adding GDB paths.
> 
> Hope this helps,
> Derek

Re: Can't find source files

[geneSmith]

Dave Korn wrote, On 10/12/2004 11:59 AM:

>>-----Original Message-----
>>From: Dickinson, Derek 
>>Sent: 12 October 2004 16:39
>>To: 'Dave Korn'; 'geneSmith'; insight
>>Subject: 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
> 
> 
> 
>   Absolutely, it's exactly the sort of problem that they were designed to
> solve.  
> 
>   Since we're discussing cygwin, I'll just mention that cygwin mountpoints
> are another handy way of translating paths between different systems.
> 
>   I was gonna suggest either/and/or/both of these in my first response to
> Gene, but then I thought it might be more interesting to solve the problem
> rather than just work round it without knowing what/how/why.
> 
> 
>     cheers, 
>       DaveK

I tried faking it out with symlinks but couldn't get it to work either. 
Not sure what the problem was, it was late. :)
-gene

-- 
Lit up like Levy's

RE: Can't find source files

[Dave Korn]

> -----Original Message-----
> From: Dickinson, Derek 
> Sent: 12 October 2004 16:39
> To: 'Dave Korn'; 'geneSmith'; insight
> Subject: 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


  Absolutely, it's exactly the sort of problem that they were designed to
solve.  

  Since we're discussing cygwin, I'll just mention that cygwin mountpoints
are another handy way of translating paths between different systems.

  I was gonna suggest either/and/or/both of these in my first response to
Gene, but then I thought it might be more interesting to solve the problem
rather than just work round it without knowing what/how/why.


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

RE: Can't find source files

[Dickinson, Derek]

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