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: probing GDB for MI versions


On Tue, Oct 19, 2004 at 09:28:24AM -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 19, 2004 at 09:19:53AM -0400, 'Bob Rossi' wrote:
> > Yes, I understand.
> > 
> > If GDB is going to support 1 stable version of the MI protocol at a time
> > then just have it print the version on startup. There is no negotiation
> > that needs to take place.
> > 
> > If GDB is going to support multiple stable versions of the MI protocol
> > at a time, then have it print all of the versions like you suggested.
> > Also, above what you suggested, I think the front end should be able to
> > select the version it wants from the list. Is this OK?
> > 
> > I'd like to work on this patch as soon as possible, so that I can start
> > using it. Is the multiple stable version approach with negotiation OK?
> 
> I think it's pretty clear that no one else likes the idea of
> negotiating.  I certainly don't.
> 
> I believe that printing the latest stable version of MI is plenty
> adequate.  If the front end wants a development version of MI it can
> use -i=mi; if it wants the latest stable version it can use that
> version; if it does not recognize that version it can use the latest
> version it recognizes.  If you encounter a situation in which that
> version no longer works, have it removed from GDB.

OK, I want to make it clear that I think this solution is terrible.
However, hoping that the GDB community knows more than I, I'll agree.

Starting GDB with -i=mi<n> will not change the MI output. However,
starting GDB with -i=mi will have GDB print the latest stable version
even though it will start GDB in it's latest development version or the
latest stable version. For some odd reason in this mode, GDB will print 
the latest stable version even though it may have absolutely nothing to 
do with the version it will be communicating with.

So, I'll basically start GDB with -i=mi and get the latest stable
version. However, since I won't know what version I just started GDB in,
the version it just spat out, or a development version, I'll *have* to
restart GDB no matter what.

So, I'll read the first line ( which is the latest stable version ), and 
then kill GDB and restart it in the mode that I support.

This solution,

   * *requires* a restart
   * requires printing the latest stable version even though GDB may not be 
     even speaking that version
   * says *nothing* about other versions that GDB supports
   * gives no way for a front end to determine if it is using a
     deprecated protocol.
   * puts the bug finding of the MI protocol on the users, even though the 
     protocols have been deprecated.

If this is the wish of the GDB community, then this is what I'll implement.

Thanks,
Bob Rossi


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