This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB/MI snapshots between major release's


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?
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]