From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eli Zaretskii" To: tromey@redhat.com Cc: gdb@sources.redhat.com, bug-gnu-emacs@gnu.org Subject: Re: Using gdb with emacs Date: Fri, 07 Sep 2001 01:01:00 -0000 Message-id: <2593-Fri07Sep2001105921+0300-eliz@is.elta.co.il> References: <874rqfvl52.fsf@creche.redhat.com> X-SW-Source: 2001-09/msg00055.html > From: Tom Tromey > 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.