* MI documentation @ 2004-09-29 17:31 Bob Rossi 2004-09-30 6:36 ` Fabian Cenedese 2004-09-30 13:55 ` Eli Zaretskii 0 siblings, 2 replies; 6+ messages in thread From: Bob Rossi @ 2004-09-29 17:31 UTC (permalink / raw) To: gdb; +Cc: eliz, cagney, ezannoni, fnasser Hi, I was wondering how GDB documents the different versions of MI. For instance, how do you know what MI commands are available with specific versions of MI? What fields do the commands output for specific versions? What asynchronous notifications are possibly outputted with MI version 1,2,3? Thanks, Bob Rossi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MI documentation 2004-09-29 17:31 MI documentation Bob Rossi @ 2004-09-30 6:36 ` Fabian Cenedese 2004-09-30 11:49 ` Bob Rossi 2004-09-30 13:55 ` Eli Zaretskii 1 sibling, 1 reply; 6+ messages in thread From: Fabian Cenedese @ 2004-09-30 6:36 UTC (permalink / raw) To: gdb >I was wondering how GDB documents the different versions of MI. For >instance, how do you know what MI commands are available with >specific versions of MI? What fields do the commands output for >specific versions? What asynchronous notifications are possibly outputted >with MI version 1,2,3? I think the way to go is the probing of each needed command. If it's available the frontend can use it, if not the frontend needs a fallback. This is done e.g. in the remote protocol. If the vCont command is not implemented the simpler s and c commands are used. This is somehow similar to the MI. If the tagged commands are not implemented (older gdb) the untagged commands can be used, even with less reliability. So THE ONE version number is not really usefull as you also stated earlier. But I don't know how a frontend can _ask_ what async notifications could come. bye Fabi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MI documentation 2004-09-30 6:36 ` Fabian Cenedese @ 2004-09-30 11:49 ` Bob Rossi 2004-09-30 14:01 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Bob Rossi @ 2004-09-30 11:49 UTC (permalink / raw) To: Fabian Cenedese; +Cc: gdb On Thu, Sep 30, 2004 at 08:34:58AM +0200, Fabian Cenedese wrote: > > >I was wondering how GDB documents the different versions of MI. For > >instance, how do you know what MI commands are available with > >specific versions of MI? What fields do the commands output for > >specific versions? What asynchronous notifications are possibly outputted > >with MI version 1,2,3? > > I think the way to go is the probing of each needed command. If it's > available the frontend can use it, if not the frontend needs a fallback. > This is done e.g. in the remote protocol. If the vCont command is not > implemented the simpler s and c commands are used. This is somehow > similar to the MI. If the tagged commands are not implemented (older > gdb) the untagged commands can be used, even with less reliability. > So THE ONE version number is not really usefull as you also stated > earlier. But I don't know how a frontend can _ask_ what async > notifications could come. So that only answers what syncronous commands are avaiable with the current version even thought the front end wouldn't know the version number. 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. Bob Rossi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MI documentation 2004-09-30 11:49 ` Bob Rossi @ 2004-09-30 14:01 ` Eli Zaretskii 2004-09-30 20:55 ` Bob Rossi 0 siblings, 1 reply; 6+ messages in thread From: Eli Zaretskii @ 2004-09-30 14:01 UTC (permalink / raw) To: Bob Rossi; +Cc: Cenedese, gdb > 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MI documentation 2004-09-30 14:01 ` Eli Zaretskii @ 2004-09-30 20:55 ` Bob Rossi 0 siblings, 0 replies; 6+ messages in thread From: Bob Rossi @ 2004-09-30 20:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Cenedese, gdb 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MI documentation 2004-09-29 17:31 MI documentation Bob Rossi 2004-09-30 6:36 ` Fabian Cenedese @ 2004-09-30 13:55 ` Eli Zaretskii 1 sibling, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2004-09-30 13:55 UTC (permalink / raw) To: Bob Rossi; +Cc: gdb, cagney, ezannoni, fnasser > Date: Wed, 29 Sep 2004 13:31:33 -0400 > From: Bob Rossi <bob@brasko.net> > Cc: eliz@gnu.org, cagney@redhat.com, ezannoni@redhat.com, > fnasser@redhat.com > > I was wondering how GDB documents the different versions of MI. For > instance, how do you know what MI commands are available with > specific versions of MI? By ``version'' do you mean version 1 vs version 2 (as in "-interpreter=mi2"), or the MI version shipped with GDB 6.1 vs the version shipped with GDB 6.0? > What fields do the commands output for > specific versions? What asynchronous notifications are possibly outputted > with MI version 1,2,3? That seems to say that you mean the former, but I'm still not sure. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-09-30 20:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-09-29 17:31 MI documentation 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 2004-09-30 13:55 ` Eli Zaretskii
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox