From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Tromey To: Gdb List Cc: Emacs Bug List Subject: Using gdb with emacs Date: Thu, 06 Sep 2001 18:23:00 -0000 Message-id: <874rqfvl52.fsf@creche.redhat.com> X-SW-Source: 2001-09/msg00052.html 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