From: Andrew Cagney <ac131313@redhat.com>
To: Jim Ingham <jingham@apple.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
Date: Tue, 01 Oct 2002 13:25:00 -0000 [thread overview]
Message-ID: <3D9A04BE.5080108@redhat.com> (raw)
In-Reply-To: <CA4461F0-D563-11D6-BB61-00039379E320@apple.com>
> This is only partly true. We are actually pretty conservative about changing command output. We haven't broken annotate for a while, IIRC. The mi is more like the command output, and I think we should have the same level of conservatism about this.
One of the motivations behind the MI output was that a parser could be
written in a way that allowed it to discard anything it didn't recognize.
For instance: additional events, or additional output fields should both
simply be discarded. They shouldn't be viewed as MI changes.
The thing that is triggering mi2 is the changes to actual responses
(breakpoints as you pointed out but also others.).
Anyway, at the time of each GDB release, a decision should be made about
freezing the current MI interface and starting a new one. Here, we've
frozen mi1 and moved onto mi2's development. At some point in the
future mi2 will be frozen and development will move to mi3 (I strongly
suspect it will be pretty quick - 5.4/6.0). After a freeze, the old
syntax should hang around for a limited period of time.
The pratical translation of this is ``how long before the mi1-*.exp
files can be deleted''? My guess is two releases - here 5.3 and
5.4/6.0. That means that 5.5/6.0 (in roughly a year) there will be
released a GDB that doesn't support "mi1" -- for GDB I think that is a
long time!
Andrew
next prev parent reply other threads:[~2002-10-01 20:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1033404264.17743.ezmlm@sources.redhat.com>
2002-09-30 17:48 ` Jim Ingham
2002-10-01 9:29 ` Andrew Cagney
2002-10-01 10:34 ` Jim Ingham
2002-10-01 13:25 ` Andrew Cagney [this message]
2002-10-01 14:01 ` Jim Ingham
2002-10-01 15:10 ` Andrew Cagney
2002-10-01 15:46 ` Jim Ingham
2002-10-01 16:39 ` Keith Seitz
2002-10-01 17:45 ` Jim Ingham
2002-10-02 7:58 ` Keith Seitz
2002-10-02 10:49 ` Jim Ingham
2002-10-25 14:48 ` Andrew Cagney
2002-10-01 23:25 ` Jason Molenda
2002-10-02 10:22 ` Stan Shebs
[not found] <1035593825.16489.ezmlm@sources.redhat.com>
2002-10-25 18:22 ` Jim Ingham
2002-09-29 11:14 Andrew Cagney
2002-09-29 12:55 ` Daniel Jacobowitz
2002-09-29 13:19 ` Andrew Cagney
2002-09-29 14:37 ` Daniel Jacobowitz
2002-09-29 14:46 ` Andrew Cagney
2002-09-29 21:55 ` Daniel Jacobowitz
2002-09-30 8:03 ` Andrew Cagney
2002-09-30 8:16 ` Daniel Jacobowitz
2002-09-30 15:06 ` Andrew Cagney
2002-09-30 15:36 ` Daniel Jacobowitz
2002-09-29 22:01 ` Eli Zaretskii
2002-09-30 15:14 ` Andrew Cagney
2002-09-30 22:13 ` Eli Zaretskii
2002-10-01 14:26 ` Andrew Cagney
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=3D9A04BE.5080108@redhat.com \
--to=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jingham@apple.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