From: Tom Tromey <tromey@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sources.redhat.com, bug-gnu-emacs@gnu.org
Subject: Re: Using gdb with emacs
Date: Fri, 07 Sep 2001 13:26:00 -0000 [thread overview]
Message-ID: <87elpid9dt.fsf@creche.redhat.com> (raw)
In-Reply-To: <2593-Fri07Sep2001105921+0300-eliz@is.elta.co.il>
>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
Eli> What happens if you do this:
Eli> (gdb) dir /home/tromey/gnu/egcs/mauve/gnu/testlet/java/text/DateFormat
Eli> (gdb) break Test.java:83
Eli> Does it work then?
Yes, that will work for this particular case. But I don't think it
solves the general problem. In Mauve, all these files are compiled
(with gcj) into a single executable. Mauve has 121 directories. And
it has 20 files named "Test.java".
Eli> So I think we need at to least consider another possibility: set
Eli> things up so that all your directories are passed to GDB's dir
Eli> command, and then using the basename in the break commands should
Eli> work.
First, running 121 `dir' commands seems excessive. Second, if I run
all those `dir' commands, gdb still won't know which Test.java I mean.
How could it?
One idea would be for Emacs itself to send the `dir' command to gdb
before issuing the breakpoint. Maybe that would work ok. Is that
what you are suggesting? I would classify this as a potential
workaround, but not really a fix.
Eli> Anything else will IMHO be much more complex and, as Per quite
Eli> correctly pointed out, non-portable because different debug info
Eli> formats record file names in different forms; you just looked at one
Eli> particular type of debug info. Some types of debug info don't even
Eli> record the leading directories.
I'm not particularly concerned with situations where the debug info is
not robust. I think it is reasonable for gdb to adopt an approach of
making things work very well on robust platforms (for instance,
Linux), and then having the feature degrade gracefully on less capable
platforms. I disagree with the idea that gdb must support only the
least common denominator.
Tom
next prev parent reply other threads:[~2001-09-07 13:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-06 18:23 Tom Tromey
2001-09-06 19:56 ` Per Bothner
2001-09-07 1:01 ` Eli Zaretskii
2001-09-07 13:26 ` Tom Tromey [this message]
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=87elpid9dt.fsf@creche.redhat.com \
--to=tromey@redhat.com \
--cc=bug-gnu-emacs@gnu.org \
--cc=eliz@is.elta.co.il \
--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