GDB/MI snapshots between major release's

Felix Lee felix.1@canids.net
Mon Oct 4 15:34:00 GMT 2004


Bob Rossi <bob@brasko.net>:
> OK, at first I don't like this idea for several reasons. It seems to me
> that with this approach you could end up releasing GDB 6.0 with MI
> version 1 and GDB 6.1 with MI version 5. Meaning that there could be
> several versions of MI revisions between one major release.
> It seems that you would have to run the testsuite on every incompatible
> change that the MI protocol goes through, including several for only one
> release. Also, a front end would have to understand all of these
> revisions in hopes of working with the most recent GDB (CVS snapshots).

I really don't understand what's the problem you're trying to
solve.  MI doesn't change often.  and even if it did, each
version of MI has separate tests in the testsuite.  a front-end
doesn't have to understand any MI changes if it doesn't want to,
if it understands MI5, it should invoke gdb with
--interpreter=mi5.

if the gdb doesn't understand mi5, then you can try fallback to
--interpreter=mi1.  I don't see much benefit to a front-end
knowing more than two versions of MI, and most of the time
knowing just one should be adequate.

if your front-end tries mi5 and fails because gdb has made an
incompatible change to mi5, then that's a bug in gdb, and if that
bug gets exposed in a user version of gdb, the answer is 'your
gdb has a bug, install a non-buggy one'.

what's your failure scenario?
--



More information about the Gdb mailing list