This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
MI and backwards compatibility
- From: Bob Rossi <bob at brasko dot net>
- To: GDB <gdb at sources dot redhat dot com>
- Date: Fri, 1 Oct 2004 10:25:17 -0400
- Subject: MI and backwards compatibility
Hi,
Taking Eli's suggestion, I am starting a simple discussion here only on
how front end developers should expect there front end to work with
different versions of GDB.
>From Eli Zaretskii <eliz@gnu.org>
> 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