Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Bob Rossi <bob@brasko.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Cenedese@indel.ch, gdb@sources.redhat.com
Subject: Re: MI documentation
Date: Thu, 30 Sep 2004 20:55:00 -0000	[thread overview]
Message-ID: <20040930205514.GF2271@white> (raw)
In-Reply-To: <01c4a6f5$Blat.v2.2.2$930393a0@zahav.net.il>

On Thu, Sep 30, 2004 at 03:57:31PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 30 Sep 2004 07:49:17 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: gdb@sources.redhat.com
> > 
> > It still doesn't tell you the asyncronous commands like you mentioned or
> > the fields that are available for input commands or anything else that I
> > would need to know for certain versions.
> > 
> > I feel that knowing these things are a minimum requirement for having a
> > protocol between 2 processes.
> 
> Upon thinking about this issue, I came to a conclusion that, as
> surprising as it might sound, I don't understand the problem that bugs
> you.
> 
> All the MI versions except the latest are kept for one reason only:
> backward compatibility.  So an already existing front end should use
> the version it was written to support, while a new front end should
> use the latest version, the one invoked by "-interpreter=mi".  Doesn't
> this solve the problem?  If not, why not, and what solutions you can
> suggest to solve that?

I guess the *real* problem is how we expect a front end and multiple
versions of GDB work together. I think there needs to be a section in the
documentation that describes backwards compatibility. For instance, I
think that a front end programmed to understand mi1 should always work
with a GDB that is capable of outputting mi1. For instance, here are
some example GDB's and MI versions for demonstration,

GDB version with MI versions

   GDB 1.0 -> mi1
   GDB 2.0 -> mi1,mi2
   GDB 3.0 -> mi1,mi2
   GDB 4.0 -> mi1,mi2,mi3
   GDB 5.0 -> mi1,mi2,mi3,mi4

Front end version which understands MI version
   FE  1.0 -> mi2
   FE  2.0 -> mi2,mi3
   FE  3.0 -> mi2,mi3,mi4

So, here is an example that I don't see to far fetched within the next
few years. The question is, what does backwards compatibility mean?
This is what I expect,

FE 1.0 or after to never work with GDB 1.0
FE 1.0 to work with GDB 2.0 on using mi2.
FE 2.0 to work with GDB 2.0 and 3.0 using mi2
           and with GDB 4.0 on with mi3
FE 3.0 to work with GDB 2.0 and 3.0 using mi2
           and with GDB 4.0 with mi3
           and with GDB 5.0 with mi4

Is this what everyone else expects?

Thanks,
Bob Rossi


  reply	other threads:[~2004-09-30 20:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-29 17:31 Bob Rossi
2004-09-30  6:36 ` Fabian Cenedese
2004-09-30 11:49   ` Bob Rossi
2004-09-30 14:01     ` Eli Zaretskii
2004-09-30 20:55       ` Bob Rossi [this message]
2004-09-30 13:55 ` Eli Zaretskii

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=20040930205514.GF2271@white \
    --to=bob@brasko.net \
    --cc=Cenedese@indel.ch \
    --cc=eliz@gnu.org \
    --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