Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Gdb List <gdb@sources.redhat.com>
Cc: Emacs Bug List <bug-gnu-emacs@prep.ai.mit.edu>
Subject: Using gdb with emacs
Date: Thu, 06 Sep 2001 18:23:00 -0000	[thread overview]
Message-ID: <874rqfvl52.fsf@creche.redhat.com> (raw)

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


             reply	other threads:[~2001-09-06 18:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-06 18:23 Tom Tromey [this message]
2001-09-06 19:56 ` Per Bothner
2001-09-07  1:01 ` Eli Zaretskii
2001-09-07 13:26   ` Tom Tromey
2001-09-07 13:59     ` Tom Tromey
2001-09-08  0:36     ` Eli Zaretskii
2001-09-09  8:03       ` Richard Stallman
2001-09-09  9:17         ` Eli Zaretskii
2001-09-09 10:04       ` Per Bothner
2001-09-09 10:41         ` Eli Zaretskii
2001-09-09 21:34           ` Per Bothner
2001-09-10 15:50           ` Richard Stallman
2001-09-10 19:58       ` Tom Tromey
2001-09-11  8:16         ` Andrew Cagney
2001-09-11 11:18           ` Eli Zaretskii
2001-09-09  8:03     ` Richard Stallman
2001-09-10 20:01       ` Tom Tromey
2001-09-08  7:27   ` Richard Stallman
2001-09-08 10:22 ` Andrew Cagney
2001-09-08 10:49   ` Fernando Nasser
2001-09-08 12:54     ` Christopher Faylor
2001-09-10  9:04       ` pathmap patch dropped [was: Re: Using gdb with emacs] Jim Blandy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874rqfvl52.fsf@creche.redhat.com \
    --to=tromey@redhat.com \
    --cc=bug-gnu-emacs@prep.ai.mit.edu \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox