This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


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

Using gdb with emacs


I've found a debugging problem that spans both Emacs and gdb.  From
what I understand of the problem it has both a gdb component and an
Emacs component; hence the CC.  (gdb folks, please bear with me; your
part is at the end.)

I'm using GNU Emacs 20.5.1, and the current CVS (trunk) gdb.

I'm debugging libgcj using Mauve, a free software Java test suite.
Mauve is structured as a bunch of directories named after Java
classes; for instance tests for java.lang.String would appear in the
directory gnu/testlet/java/lang/String/.  Mauve has a fairly large
number of files with the same names; for instance `Test.java' appears
in many directories.

When I build Mauve, I make a parallel build tree and build it there
(i.e., I don't build in the source tree).

Now suppose I debug SimpleTestHarness (the basic Mauve program) using
gud mode in Emacs.  Say I'm debugging the DateFormat implementation.
The file I want to put a breakpoint in is:

    mauve/gnu/testlet/java/text/DateFormat/Test.java

I open a buffer on this file, move point to the line I want, and type
C-x SPC (aka gud-break).  In the *gud* buffer I see this:

    Breakpoint 1 at 0x80afc2d: file ../mauve/gnu/testlet/java/io/ObjectInputOutput/Test.java, line 83.

This is clearly wrong.  If I ask gdb it tells me what happened:

    (gdb) show commands
	1  break Test.java:83

Emacs stripped the directory information, and gdb simply chose some
random Test.java file (and, btw, let me note that the first few times
this happens, you don't notice, and you have a very frustrating
debugging experience).

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

I think it would make sense to change this line to something like
this, at least if using gdb on a Unix-like platform:

  (gud-def gud-break  "break %d/%f:%l"  "\C-b" "Set breakpoint at current line.")

(Perhaps it would be better to introduce a new % substitution that
does not strip directory information.)


Unfortunately -- and this is where gdb enters the picture -- that
change won't work.  Suppose I mimic the above change by typing in the
resulting command:

    (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.
Unfortunately, there's no way for Emacs to guess that that is what is
required.

I suppose one workaround would be to always run configure with an
absolute path.  That would probably work in most situations.  I'd
prefer not to have to do that.  I'm long past used to using relative
paths here.

I think it would be reasonable for gdb to do path canonicalization on
file names.  I think that would let the proposed Emacs change work
correctly.

Tom


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