Re: Using gdb with emacs

["Eli Zaretskii" <eliz@is.elta.co.il>]

> From: Tom Tromey <tromey@redhat.com>
> Date: 06 Sep 2001 19:34:49 -0600
> 
> If you look in gud.el, you can easily the code:
> 
>   (gud-def gud-break  "break %f:%l"  "\C-b" "Set breakpoint at current line.")
[...]
>     (gdb) break /home/tromey/gnu/egcs/mauve/mauve/gnu/testlet/java/text/DateFormat/Test.java:83
>     No source file named /home/tromey/gnu/egcs/mauve/mauve/gnu/testlet/java/text/DateFormat/Test.java.
> 
> The correct invocation, from gdb's point of view, is this:
> 
>     (gdb) break ../mauve/gnu/testlet/java/text/DateFormat/Test.java:83
>     Breakpoint 2 at 0x8092c41: file ../mauve/gnu/testlet/java/text/DateFormat/Test.java, line 83.
> 
> That leading `..' appears because of the way I built Mauve.

What happens if you do this:

     (gdb) dir /home/tromey/gnu/egcs/mauve/gnu/testlet/java/text/DateFormat
     (gdb) break Test.java:83

Does it work then?

See, I think GUD was written with this setup in mind: it assumes that
the directory of the files is known and is in the list searched by GDB
for sources.  That's why I think you have only %f in the gud-def you
mentioned above.

In fact, GDB itself also assumes something like that: for every object
module which states its source file name, GDB remembers both the
basename and the file name as recorded in the debug info.  That is
why, given the current buffer's default directory is where you ran GCC
to compile Test.java, you can say both "break Test.java:83" and "break
../mauve/gnu/testlet/java/text/DateFormat/Test.java:83".

So I think we need at to least consider another possibility: set
things up so that all your directories are passed to GDB's dir
command, and then using the basename in the break commands should
work.  Anything else will IMHO be much more complex and, as Per quite
correctly pointed out, non-portable because different debug info
formats record file names in different forms; you just looked at one
particular type of debug info.  Some types of debug info don't even
record the leading directories.

(In general, I think using the file names with leading directories in
GDB is a bad idea, because they depend too much on the assumption that
you debug in the same place where you compiled them.  Move the build
tree and you are toast.)

> I suppose one workaround would be to always run configure with an
> absolute path.  That would probably work in most situations.

Yes, but only for the kind of debug info which records the absolute
file name.

> I'd prefer not to have to do that.  I'm long past used to using
> relative paths here.

Alternatively, you could use local file variables to set
default-directory of Test.java to the directory where you run the
compiler.  This is ugly, though, and its side effects will probably
surprise you at some point.