Re: MI rules

Re: MI rules

[Jim Ingham]

Sorry for being so late in chiming in, but I guess I am not clear on 
exactly what the problem is here.

Xcode uses the command tokens through-out, so it always is able to 
match up the command & it's result.  We had to do some work to make 
sure that if a command like -exec-run gets the target going, and you 
come along and issue another command, you still get a running & a 
stopped that have the correct numbers.

But I don't think this would be a real problem for the FSF gdb right 
now, since there are very few real (any)asynchronous targets in actual 
use. If there are, you can look at what we had to change to get this 
working.  It was tricky IIRC, but not that bad.

Anyway, you almost always will need more information than just "what 
was the name of the MI command that I issued", right?  You can issue a 
whole bunch of "-var-create" commands, for instance, and just knowing 
that you issued -var-create isn't going to help you at all.  You need 
to tie each one to the particular variable the varobj was representing. 
  So issuing & keeping track of the tokens is pretty much mandatory 
anyway, and once you are doing that, you pretty much know how to 
interpreter each return value.

Other that that, there are the asynchronous notifications that come 
from gdb when something interesting happens, but those should already 
all have some unique tag after the "=" that tells you what the data is.

I don't have any big problem with adding the command name after the 
command token or something similar, but I don't see that it really adds 
much in practical terms.  It also looks to me like this will be a 
backwards-incompatible change to the mi, no?  If so you should bump the 
MI version if you add this.

Jim



On Sep 23, 2004, at 8:45 AM, gdb-digest-help@sources.redhat.com wrote:

>
>
> On Wed, Sep 22, 2004 at 12:18:06PM -0400, Bob Rossi wrote:
>
>> I wasn't being critical at all. Personally, I don't like the fact that
>> Eclipse use's a hybrid approach to getting data out of GDB. I have not
>> even started adding MI to CGDB because I've been working on GDB,
>> bringing it up to the standards I need to get CGDB fully usable by 
>> only
>> using MI. If others would follow this approach, I'm sure my life would
>> have been a lot easier, and CGDB would have been far more along.
>
> For what it's worth, Xcode (the IDE on MacOS X) uses something like
> one non-MI command these days ("tty").  It's true that we've done a
> lot of work on the MI side of gdb, but an example of an MI-only
> (well, nearly so - there's no bonus points for having 100% MI usage
> so we have that one command there) exists and has been shipping for
> at least a few years now.  NB Xcode is gratis free, but not libre free,
> i.e. not free software.
>
> J

Re: MI rules

[Bob Rossi]

On Thu, Sep 23, 2004 at 11:23:18AM -0700, Jim Ingham wrote:
> Sorry for being so late in chiming in, but I guess I am not clear on 
> exactly what the problem is here.

Don't be, thanks for responding.

> Xcode uses the command tokens through-out, so it always is able to 
> match up the command & it's result.  We had to do some work to make 
> sure that if a command like -exec-run gets the target going, and you 
> come along and issue another command, you still get a running & a 
> stopped that have the correct numbers.
> 
> But I don't think this would be a real problem for the FSF gdb right 
> now, since there are very few real (any)asynchronous targets in actual 
> use. If there are, you can look at what we had to change to get this 
> working.  It was tricky IIRC, but not that bad.

OK, I understand that it is possible to use the tokens to be able to
tell what MI output commands is coming out of GDB when it is issuing
syncronous commands.

> 
> Anyway, you almost always will need more information than just "what 
> was the name of the MI command that I issued", right?  You can issue a 
> whole bunch of "-var-create" commands, for instance, and just knowing 
> that you issued -var-create isn't going to help you at all.  You need 
> to tie each one to the particular variable the varobj was representing. 
>  So issuing & keeping track of the tokens is pretty much mandatory 
> anyway, and once you are doing that, you pretty much know how to 
> interpreter each return value.

This is a good point. I haven't got this far in my implementation.

> Other that that, there are the asynchronous notifications that come 
> from gdb when something interesting happens, but those should already 
> all have some unique tag after the "=" that tells you what the data is.
> 
> I don't have any big problem with adding the command name after the 
> command token or something similar, but I don't see that it really adds 
> much in practical terms.  It also looks to me like this will be a 
> backwards-incompatible change to the mi, no?  If so you should bump the 
> MI version if you add this.

Please take a look at 
http://sources.redhat.com/ml/gdb/2004-09/msg00200.html

I have summarized the two issues better there. One of the issues is more
important, and that deals with MI outuput commands and backwards
compatibility.

Finally, I personally think that every MI output command should self
document what type of command it is. This tells the front end easily
what kind of MI output command walker should be used to understand the
data. I understand the front end could use the tokens to figure it out,
but I think it's something that should be self evident from having the
MI output command. 

Finally, for instances like -var-create I would suggest adding a new
field to the -var-create that gives it a unique id ( like tokens ).
Then, whenever a -var- response from GDB it should tell you that it is
issuing a -var-create response and it is tied to the unique id. That way
the front end can match it up.

Personally, I think all of these things can be done easily at the GDB
level and can avoid unnecessary confusion in the front ends.

Does it sound unreasonable for a MI output command, either syncronous or
asyncronous to say what kind of command it is?

Input is greatly appreciated since I've already made it passed the
parsing stage of the MI output commands and want to start interpretting
the data. Basically, I hope that the bison parser that I have will be
usable by other front end developers one day. I also think that for each
MI output command that they get, they should be able to understand how
to interpret the data, without having to do lookups to figure out what
type of command it is, or wihtout having to look at the data to figure
out what kind of command it is.

Thanks,
Bob Rossi

Re: MI rules

[Jim Ingham]

I have no strong opposition to this, I just don't see the point.

I think any sane implementation of the MI driver is going to want to 
use the command tokens to keep track of the commands that are issued, 
to make sure something hasn't been dropped on the floor, do good error 
reporting - "Which command was it that went wrong..." etc.  And once 
you are doing that, you always know exactly what command you issued and 
what you got back.

OTOH, adding some kind of command identifier to the return is mostly 
pretty easy, you can just hook into the mechanism that issues the 
command token.  Note that this code is not quite as trivial as it seems 
- and I think the FSF version doesn't work correctly in all cases - 
particularly with async targets, and when you allow things like 
breakpoint commands.

For instance if you allow breakpoint commands that can cause the target 
to run (like a "continue" in a breakpoint command) for an asynchronous 
target, you will get a stopped message, but then you have to issue 
another ^running and maybe some indication of what happened to the GUI, 
and all these are bound to the original -exec-continue or whatever got 
the target going.

I fixed a bunch of this stuff on our side, and I don't remember seeing 
similar work go on on the FSF side (though I may have missed it).  
Sadly that sits on top of a pile of other changes to support 
asynchronous targets that only exist on our side...  But you should at 
least be aware that this is not entirely straight-forward...

OTOH, if you ever get to your goal of having a data-driven validator 
for the command returns, I can see it might be useful.

A few specific comments below...


On Sep 24, 2004, at 6:05 PM, Bob Rossi wrote:

> On Thu, Sep 23, 2004 at 11:23:18AM -0700, Jim Ingham wrote:
>> Sorry for being so late in chiming in, but I guess I am not clear on
>> exactly what the problem is here.
>
> Don't be, thanks for responding.
>
>> Xcode uses the command tokens through-out, so it always is able to
>> match up the command & it's result.  We had to do some work to make
>> sure that if a command like -exec-run gets the target going, and you
>> come along and issue another command, you still get a running & a
>> stopped that have the correct numbers.
>>
>> But I don't think this would be a real problem for the FSF gdb right
>> now, since there are very few real (any)asynchronous targets in actual
>> use. If there are, you can look at what we had to change to get this
>> working.  It was tricky IIRC, but not that bad.
>
> OK, I understand that it is possible to use the tokens to be able to
> tell what MI output commands is coming out of GDB when it is issuing
> syncronous commands.
>
>>
>> Anyway, you almost always will need more information than just "what
>> was the name of the MI command that I issued", right?  You can issue a
>> whole bunch of "-var-create" commands, for instance, and just knowing
>> that you issued -var-create isn't going to help you at all.  You need
>> to tie each one to the particular variable the varobj was 
>> representing.
>>  So issuing & keeping track of the tokens is pretty much mandatory
>> anyway, and once you are doing that, you pretty much know how to
>> interpreter each return value.
>
> This is a good point. I haven't got this far in my implementation.
>
>> Other that that, there are the asynchronous notifications that come
>> from gdb when something interesting happens, but those should already
>> all have some unique tag after the "=" that tells you what the data 
>> is.
>>
>> I don't have any big problem with adding the command name after the
>> command token or something similar, but I don't see that it really 
>> adds
>> much in practical terms.  It also looks to me like this will be a
>> backwards-incompatible change to the mi, no?  If so you should bump 
>> the
>> MI version if you add this.
>
> Please take a look at
> http://sources.redhat.com/ml/gdb/2004-09/msg00200.html
>
> I have summarized the two issues better there. One of the issues is 
> more
> important, and that deals with MI outuput commands and backwards
> compatibility.
>
> Finally, I personally think that every MI output command should self
> document what type of command it is. This tells the front end easily
> what kind of MI output command walker should be used to understand the
> data. I understand the front end could use the tokens to figure it out,
> but I think it's something that should be self evident from having the
> MI output command.

This has just never come up in the 4 years I have been supporting the 
Xcode guys.  There are LOTS of things they want from us, some of which 
we have provided, some not.  But this one has never seemed a problem.

>
> Finally, for instances like -var-create I would suggest adding a new
> field to the -var-create that gives it a unique id ( like tokens ).
> Then, whenever a -var- response from GDB it should tell you that it is
> issuing a -var-create response and it is tied to the unique id. That 
> way
> the front end can match it up.

This IS what the command tokens are for.  I don't at all think it is a 
good idea to replicate this mechanism.  As it stands it works just 
fine, and I don't see any point in doing it twice, that just introduces 
more chances for bugs.  And you certainly want a general mechanism to 
tag every command you issue, so you can't replace it with a command 
specific mechanism.

>
> Personally, I think all of these things can be done easily at the GDB
> level and can avoid unnecessary confusion in the front ends.
>
> Does it sound unreasonable for a MI output command, either syncronous 
> or
> asyncronous to say what kind of command it is?

Not unreasonable, just more code that we have to maintain for what 
seems to me like marginal benefit.

Tracking the tokens and getting them to be right is not quite as 
trivial as it seems, and this just adds a little more weight to that 
mechanism.  But given that that already works, if you can hook onto 
that you can probably do it without adding to much of a maintenance 
burden.

It will probably also be an incompatible change, so you will have to 
mark it as such.

>
> Input is greatly appreciated since I've already made it passed the
> parsing stage of the MI output commands and want to start interpretting
> the data. Basically, I hope that the bison parser that I have will be
> usable by other front end developers one day. I also think that for 
> each
> MI output command that they get, they should be able to understand how
> to interpret the data, without having to do lookups to figure out what
> type of command it is, or wihtout having to look at the data to figure
> out what kind of command it is.
>
> Thanks,
> Bob Rossi
>

Jim
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb

Re: MI rules

[Bob Rossi]

On Sat, Sep 25, 2004 at 12:01:28PM -0700, Jim Ingham wrote:
> I have no strong opposition to this, I just don't see the point.
> 

Jim, I appreciate the time you have spent thinking about this issue for
me. I value the input from someone who has been working with MI for
quite some time. I have several questions for you,

   1. How do you figure out what type of asynchronous MI output command
   you just received is? 

   2. How do you deal with your MI front end dealing with snapshots of
   GDB? For example, it has new asynchronous commands, but the MI version 
   hasn't been bumped yet.


Finally, I want to make an analogy and I would like for someone to tell
me where my thinking went wrong.

   GDB and a leaf collecting hobbyist are best friends. For some odd reason,
   GDB has tons of different kinds of leafs and the hobbyist is just
   getting his collection started. The hobbyist, named Foo, often asks
   GDB for a particular kind of leaf, knowing that GDB has it. Since GDB
   is willing to get rid of some of his collection, he sends to Foo the
   leaf every time. Sometimes, when GDB finds an extra leaf, he sends it to
   Foo, even though Foo didn't ask for it. The only problem is, Foo can not
   figure out what kind of leaf he got, since there are several others
   that look almost exactly like it. So Foo spends a large portion of
   the time guessing what kind of leaf he was just given, even though
   GDB could have just put on the envelope the type of leaf that it
   was. Foo can not understand why GDB is so mysterious about the leafs
   he hands out. The end.

hehe, anyways, I'm interested in hearing how you solve the top two
problems.

Thanks,
Bob Rossi

Re: MI rules

[Jim Ingham]

On Sep 25, 2004, at 1:12 PM, Bob Rossi wrote:

> On Sat, Sep 25, 2004 at 12:01:28PM -0700, Jim Ingham wrote:
>> I have no strong opposition to this, I just don't see the point.
>>
>
> Jim, I appreciate the time you have spent thinking about this issue for
> me. I value the input from someone who has been working with MI for
> quite some time. I have several questions for you,
>
>    1. How do you figure out what type of asynchronous MI output command
>    you just received is?

There are two things here - there is asynchronous output from an MI  
command, like stopped, running, etc.  We added "running breakpoint  
command message so you can tell that it might start up again..."  This  
sort of thing - usually from running.  They are always linked to the  
original command by preserving the command token.  So that's easy.

Then there is true asynchronous communications from the inferior -  
unsolicited messages like shared library notification, or the fact that  
a user command ("interpreter-exec") caused a breakpoint to be set, the  
thread or the frame to be changed, etc...  These are all dealt with  
just as you suggest for commands - they have a tag at the beginning  
specifying the kind of event.  So for instance, when a shared library  
gets loaded, we get:

=shlibs-added,shlib-info= 
[num="6",name="PBGDBIntrospectionSupport.A.dylib",kind="-",dyld- 
addr="0x83d50000",reason="dyld",requested- 
state="?",state="N",path="",description="/Developer/Applications/ 
Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/ 
PBGDBIntrospectionSupport.A.dylib",slide="",addr="",prefix=""]

We are also a bit behind the times, and still use the HOOKS - haven't  
got around to absorbing Andrew's observers yet...  So we also get stuff  
like:

-interpreter-exec console "break captured_main"
Breakpoint 3 at 0x2960: file ../../gdb/src/gdb/main.c, line 122.
^done,MI_HOOK_RESULT={HOOK_TYPE="breakpoint_create",bkpt= 
{number="3",type="breakpoint",disp="keep",enabled="y",addr="0x00002960", 
func="captured_main",file="../../gdb/src/gdb/ 
main.c",line="122",times="0"}}

Again, the truely unsolicited stuff (in this case the breakpoint  
creation notification) is all tagged so the UI can figure out what is  
going on.


>
>    2. How do you deal with your MI front end dealing with snapshots of
>    GDB? For example, it has new asynchronous commands, but the MI  
> version
>    hasn't been bumped yet.

There are two kinds of additions, right?  Command return fields, and  
async notifications.  In Xcode,
the parser parses everything, and then any command return fields or  
async notifications that it doesn't understand, it ignores.  That's  
pretty much how the MI was designed, so that the MI can freely ADD  
notifications & command return fields, and the UI can just ignore them.  
  The fields are identified by field name, and the notifications by  
their notification name.

If we were to take away a field the UI wanted, then Xcode would  
probably yell at us.  But we don't generally do that, we just add  
stuff.  And of course you can't change the meaning of command arguments  
- that's why Jason has been on the rampage about positional commands in  
the mi - it would be MUCH more robust if they were all of the "command  
-switch value -switch value" type, then they would share the robustness  
of the mi output.

>
>
> Finally, I want to make an analogy and I would like for someone to tell
> me where my thinking went wrong.
>
>    GDB and a leaf collecting hobbyist are best friends. For some odd  
> reason,
>    GDB has tons of different kinds of leafs and the hobbyist is just
>    getting his collection started. The hobbyist, named Foo, often asks
>    GDB for a particular kind of leaf, knowing that GDB has it. Since  
> GDB
>    is willing to get rid of some of his collection, he sends to Foo the
>    leaf every time. Sometimes, when GDB finds an extra leaf, he sends  
> it to
>    Foo, even though Foo didn't ask for it. The only problem is, Foo  
> can not
>    figure out what kind of leaf he got, since there are several others
>    that look almost exactly like it. So Foo spends a large portion of
>    the time guessing what kind of leaf he was just given, even though
>    GDB could have just put on the envelope the type of leaf that it
>    was. Foo can not understand why GDB is so mysterious about the leafs
>    he hands out. The end.
>
> hehe, anyways, I'm interested in hearing how you solve the top two
> problems.

We have never really had problems like this.  We send lots of  
notifications that Xcode ignores.  Of course, we might be sending one  
that it really OUGHT to take into account, but if that's true, just  
identifying the notification wouldn't help, it would have to know what  
to do about it.  This sort of reactive logic would be pretty hard to  
run in a data-driven way, so it's probably best to just ignore them,  
get the bug report that something went wrong & Xcode didn't notice it,  
and then go fix Xcode for the next release.

Jim

Re: MI rules

[Bob Rossi]

I have one quick note. I would prefer to get some cooperation with the
MI maintainers. I seriously need this cooperation in order to get
anything done with CGDB. Also, I consider the work I am doing necessary
for any front end developer to be able to write a reasonable front end
without having to heavily patch a version of GDB they distribute with.

If you consider my goal worthy, please at least respond with some
reasonable criticism so that these issues can be resolved. I feel that in
many ways my views on the MI are mostly ignored by the MI maintainers.
I would like to improve GDB in the areas that seem relevant to front end
developers and am assuming that you all have the same goal. So
hopefully these issues and the ones in the future can be resolved within
a reasonable amount of time.


On Mon, Sep 27, 2004 at 10:38:55AM -0700, Jim Ingham wrote:
> 
> On Sep 25, 2004, at 1:12 PM, Bob Rossi wrote:
> 
> >On Sat, Sep 25, 2004 at 12:01:28PM -0700, Jim Ingham wrote:
> >>I have no strong opposition to this, I just don't see the point.
> >>
> >
> >Jim, I appreciate the time you have spent thinking about this issue for
> >me. I value the input from someone who has been working with MI for
> >quite some time. I have several questions for you,
> >
> >   1. How do you figure out what type of asynchronous MI output command
> >   you just received is?
> 
> There are two things here - there is asynchronous output from an MI  
> command, like stopped, running, etc.  We added "running breakpoint  
> command message so you can tell that it might start up again..."  This  
> sort of thing - usually from running.  They are always linked to the  
> original command by preserving the command token.  So that's easy.
> 
> Then there is true asynchronous communications from the inferior -  
> unsolicited messages like shared library notification, or the fact that  
> a user command ("interpreter-exec") caused a breakpoint to be set, the  
> thread or the frame to be changed, etc...  These are all dealt with  
> just as you suggest for commands - they have a tag at the beginning  
> specifying the kind of event.  So for instance, when a shared library  
> gets loaded, we get:
> 
> =shlibs-added,shlib-info= 
> [num="6",name="PBGDBIntrospectionSupport.A.dylib",kind="-",dyld- 
> addr="0x83d50000",reason="dyld",requested- 
> state="?",state="N",path="",description="/Developer/Applications/ 
> Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/ 
> PBGDBIntrospectionSupport.A.dylib",slide="",addr="",prefix=""]

OK, so this is exactly what I'm talking about. There needs to be a label
for asynchronous commands. I guess it's not necessary for synchronous
commands but I think it could be useful to have there anyways and it
would be trivial to add.

> Again, the truely unsolicited stuff (in this case the breakpoint  
> creation notification) is all tagged so the UI can figure out what is  
> going on.

I think this also needs to be done in the mainline GDB and I would
prefer the synchronous commands to get a tag also. Do you agree with the
asynchronous part at least?

> >   2. How do you deal with your MI front end dealing with snapshots of
> >   GDB? For example, it has new asynchronous commands, but the MI  
> >version
> >   hasn't been bumped yet.
> 
> There are two kinds of additions, right?  Command return fields, and  
> async notifications.  In Xcode,
> the parser parses everything, and then any command return fields or  
> async notifications that it doesn't understand, it ignores.  That's  
> pretty much how the MI was designed, so that the MI can freely ADD  
> notifications & command return fields, and the UI can just ignore them.  
>  The fields are identified by field name, and the notifications by  
> their notification name.

OK, so understood.

Commands that add a field will definatly work because the front end
ignores them. Commands that loose a field will probably cause a major
problem and will be incompatible with the front end.

What about when a command changes completly because of a version bump?
What about when the commands changes (like N:M breakpoints) and the
version is not bumped yet because you have a snapshot of GDB?

I need these case's to work because I am not bundled with GDB.

So again, I'm asking everyone, 

1. Can the mainline version get tagged asyncronous commands at the least? 
I would prefer every command to have a tag.

2. Can there be a discussion about backwards compatibility with MI
output commands. This involves several issues I can think of.
   1. removing fields from an MI output command
   2. changing the output of an MI output command
   3. Making the commands themselves be backwards compatible even
   between major releases. This essentially makes the MI output version
   useless.

Thanks,
Bob Rossi

Re: MI rules

[Jim Ingham]

Bob,

First, I think parts of the discussion are unclear because you are a 
little lax on terminology.  What you are calling asynchronous COMMANDS 
are really asynchronous NOTIFICATIONS.  They aren't the result of a 
command, but something that happens in gdb that gdb decides it ought to 
tell you about.  There are actually different mechanisms to emit them 
in gdb, so they are clearly separated in the code.

And yes, ALL asynchronous notifications need to be tagged.  I haven't 
played around with TOT without our modifications, so I can't actually 
tell you what the state is there, but if this isn't the case it 
certainly ought to be.  I would be surprised if they weren't, but...

About incompatible changes.  I see the need to have a stable version of 
the MI so that you can deliver a front end that will work with some 
reasonable range of gdb's.  OTOH, putting a whole lot of effort into 
making your front end work with every possible variant of the 
development versions of the MI seems to me like a misdirection of our 
limited resources. The current state falls short of your needs right 
now because you need to use the development version only, and until 
that is stable, you are in a bind.  But over designing for a side 
effect of the software not being all the way done is not as good a use 
of resources as actually getting a stable version that has what you 
need...

The thing I think we really need to work on (besides tagging 
notifications if there is any place they aren't tagged) is making the 
command INPUT more robust.  The output is already pretty good, there is 
seldom a need to remove fields, and adding fields is done in a way that 
the client can handle.  But the command input is not similarly 
self-labeling, and thus much more fragile.

Jim

On Sep 28, 2004, at 7:59 PM, Bob Rossi wrote:

> I have one quick note. I would prefer to get some cooperation with the
> MI maintainers. I seriously need this cooperation in order to get
> anything done with CGDB. Also, I consider the work I am doing necessary
> for any front end developer to be able to write a reasonable front end
> without having to heavily patch a version of GDB they distribute with.
>
> If you consider my goal worthy, please at least respond with some
> reasonable criticism so that these issues can be resolved. I feel that 
> in
> many ways my views on the MI are mostly ignored by the MI maintainers.
> I would like to improve GDB in the areas that seem relevant to front 
> end
> developers and am assuming that you all have the same goal. So
> hopefully these issues and the ones in the future can be resolved 
> within
> a reasonable amount of time.
>
>
> On Mon, Sep 27, 2004 at 10:38:55AM -0700, Jim Ingham wrote:
>>
>> On Sep 25, 2004, at 1:12 PM, Bob Rossi wrote:
>>
>>> On Sat, Sep 25, 2004 at 12:01:28PM -0700, Jim Ingham wrote:
>>>> I have no strong opposition to this, I just don't see the point.
>>>>
>>>
>>> Jim, I appreciate the time you have spent thinking about this issue 
>>> for
>>> me. I value the input from someone who has been working with MI for
>>> quite some time. I have several questions for you,
>>>
>>>   1. How do you figure out what type of asynchronous MI output 
>>> command
>>>   you just received is?
>>
>> There are two things here - there is asynchronous output from an MI
>> command, like stopped, running, etc.  We added "running breakpoint
>> command message so you can tell that it might start up again..."  This
>> sort of thing - usually from running.  They are always linked to the
>> original command by preserving the command token.  So that's easy.
>>
>> Then there is true asynchronous communications from the inferior -
>> unsolicited messages like shared library notification, or the fact 
>> that
>> a user command ("interpreter-exec") caused a breakpoint to be set, the
>> thread or the frame to be changed, etc...  These are all dealt with
>> just as you suggest for commands - they have a tag at the beginning
>> specifying the kind of event.  So for instance, when a shared library
>> gets loaded, we get:
>>
>> =shlibs-added,shlib-info=
>> [num="6",name="PBGDBIntrospectionSupport.A.dylib",kind="-",dyld-
>> addr="0x83d50000",reason="dyld",requested-
>> state="?",state="N",path="",description="/Developer/Applications/
>> Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/
>> PBGDBIntrospectionSupport.A.dylib",slide="",addr="",prefix=""]
>
> OK, so this is exactly what I'm talking about. There needs to be a 
> label
> for asynchronous commands. I guess it's not necessary for synchronous
> commands but I think it could be useful to have there anyways and it
> would be trivial to add.
>
>> Again, the truely unsolicited stuff (in this case the breakpoint
>> creation notification) is all tagged so the UI can figure out what is
>> going on.
>
> I think this also needs to be done in the mainline GDB and I would
> prefer the synchronous commands to get a tag also. Do you agree with 
> the
> asynchronous part at least?
>
>>>   2. How do you deal with your MI front end dealing with snapshots of
>>>   GDB? For example, it has new asynchronous commands, but the MI
>>> version
>>>   hasn't been bumped yet.
>>
>> There are two kinds of additions, right?  Command return fields, and
>> async notifications.  In Xcode,
>> the parser parses everything, and then any command return fields or
>> async notifications that it doesn't understand, it ignores.  That's
>> pretty much how the MI was designed, so that the MI can freely ADD
>> notifications & command return fields, and the UI can just ignore 
>> them.
>>  The fields are identified by field name, and the notifications by
>> their notification name.
>
> OK, so understood.
>
> Commands that add a field will definatly work because the front end
> ignores them. Commands that loose a field will probably cause a major
> problem and will be incompatible with the front end.
>
> What about when a command changes completly because of a version bump?
> What about when the commands changes (like N:M breakpoints) and the
> version is not bumped yet because you have a snapshot of GDB?
>
> I need these case's to work because I am not bundled with GDB.
>
> So again, I'm asking everyone,
>
> 1. Can the mainline version get tagged asyncronous commands at the 
> least?
> I would prefer every command to have a tag.
>
> 2. Can there be a discussion about backwards compatibility with MI
> output commands. This involves several issues I can think of.
>    1. removing fields from an MI output command
>    2. changing the output of an MI output command
>    3. Making the commands themselves be backwards compatible even
>    between major releases. This essentially makes the MI output version
>    useless.
>
> Thanks,
> Bob Rossi
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: MI rules

[Bob Rossi]

Hi Jim,

Thanks again for taking the time to discuss this with me.

On Wed, Sep 29, 2004 at 09:13:41AM -0700, Jim Ingham wrote:
> Bob,
> 
> First, I think parts of the discussion are unclear because you are a 
> little lax on terminology.  What you are calling asynchronous COMMANDS 
> are really asynchronous NOTIFICATIONS.  They aren't the result of a 
> command, but something that happens in gdb that gdb decides it ought to 
> tell you about.  There are actually different mechanisms to emit them 
> in gdb, so they are clearly separated in the code.

OK, understood that there is some miscommunication. I refer to all
output commands as MI output commands, if they are asyncronous or not. I
picked this terminology up from the manual at 24.1.2 GDB/MI Output Syntax.

The async-record is in particular what I mean when I say asyncronous and
it is part of an MI output command. I believe that at least these
asyncronous MI output commands need to have a tag in order for the front
end to undestand what kind of MI output command ( asyncronous
notification ) is being sent from GDB.

> And yes, ALL asynchronous notifications need to be tagged.  I haven't 
> played around with TOT without our modifications, so I can't actually 
> tell you what the state is there, but if this isn't the case it 
> certainly ought to be.  I would be surprised if they weren't, but...

The tag is not in the grammer. So, if it is actually outputted by GDB
then I would be very happy because just the grammer needs to be updated.
However, if it the grammer is correct, I need this in the mainline GDB
to get some reasonable work done. I would be happy to work on the
implemenation, unless of course you already have a patch that does just
what I need.

> About incompatible changes.  I see the need to have a stable version of 
> the MI so that you can deliver a front end that will work with some 
> reasonable range of gdb's.  OTOH, putting a whole lot of effort into 
> making your front end work with every possible variant of the 
> development versions of the MI seems to me like a misdirection of our 
> limited resources. The current state falls short of your needs right 
> now because you need to use the development version only, and until 
> that is stable, you are in a bind.  But over designing for a side 
> effect of the software not being all the way done is not as good a use 
> of resources as actually getting a stable version that has what you 
> need...

I understand what you are saying. Unfortunatly the reality is that many
major distributions ( debian ) take a snapshot of GDB, instead of
waiting for a major release. Because of this, front ends would not work
out of the box on normal distributions. This seems unreasonable.

> The thing I think we really need to work on (besides tagging 
> notifications if there is any place they aren't tagged) is making the 
> command INPUT more robust.  The output is already pretty good, there is 
> seldom a need to remove fields, and adding fields is done in a way that 
> the client can handle.  But the command input is not similarly 
> self-labeling, and thus much more fragile.

I am very willing to work on the MI input commands. I'm sure I'll be
making a lot of noise when I get to that point. However, I haven't
even gotten to that point because I am trying to design and implement
the parsing of the MI output commands. Until I can get that working
properly, I can't even think about the input commands.

> 
> Jim
> 
> On Sep 28, 2004, at 7:59 PM, Bob Rossi wrote:
> 
> >I have one quick note. I would prefer to get some cooperation with the
> >MI maintainers. I seriously need this cooperation in order to get
> >anything done with CGDB. Also, I consider the work I am doing necessary
> >for any front end developer to be able to write a reasonable front end
> >without having to heavily patch a version of GDB they distribute with.
> >
> >If you consider my goal worthy, please at least respond with some
> >reasonable criticism so that these issues can be resolved. I feel that 
> >in
> >many ways my views on the MI are mostly ignored by the MI maintainers.
> >I would like to improve GDB in the areas that seem relevant to front 
> >end
> >developers and am assuming that you all have the same goal. So
> >hopefully these issues and the ones in the future can be resolved 
> >within
> >a reasonable amount of time.
> >
> >
> >On Mon, Sep 27, 2004 at 10:38:55AM -0700, Jim Ingham wrote:
> >>
> >>On Sep 25, 2004, at 1:12 PM, Bob Rossi wrote:
> >>
> >>>On Sat, Sep 25, 2004 at 12:01:28PM -0700, Jim Ingham wrote:
> >>>>I have no strong opposition to this, I just don't see the point.
> >>>>
> >>>
> >>>Jim, I appreciate the time you have spent thinking about this issue 
> >>>for
> >>>me. I value the input from someone who has been working with MI for
> >>>quite some time. I have several questions for you,
> >>>
> >>>  1. How do you figure out what type of asynchronous MI output 
> >>>command
> >>>  you just received is?
> >>
> >>There are two things here - there is asynchronous output from an MI
> >>command, like stopped, running, etc.  We added "running breakpoint
> >>command message so you can tell that it might start up again..."  This
> >>sort of thing - usually from running.  They are always linked to the
> >>original command by preserving the command token.  So that's easy.
> >>
> >>Then there is true asynchronous communications from the inferior -
> >>unsolicited messages like shared library notification, or the fact 
> >>that
> >>a user command ("interpreter-exec") caused a breakpoint to be set, the
> >>thread or the frame to be changed, etc...  These are all dealt with
> >>just as you suggest for commands - they have a tag at the beginning
> >>specifying the kind of event.  So for instance, when a shared library
> >>gets loaded, we get:
> >>
> >>=shlibs-added,shlib-info=
> >>[num="6",name="PBGDBIntrospectionSupport.A.dylib",kind="-",dyld-
> >>addr="0x83d50000",reason="dyld",requested-
> >>state="?",state="N",path="",description="/Developer/Applications/
> >>Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/
> >>PBGDBIntrospectionSupport.A.dylib",slide="",addr="",prefix=""]
> >
> >OK, so this is exactly what I'm talking about. There needs to be a 
> >label
> >for asynchronous commands. I guess it's not necessary for synchronous
> >commands but I think it could be useful to have there anyways and it
> >would be trivial to add.
> >
> >>Again, the truely unsolicited stuff (in this case the breakpoint
> >>creation notification) is all tagged so the UI can figure out what is
> >>going on.
> >
> >I think this also needs to be done in the mainline GDB and I would
> >prefer the synchronous commands to get a tag also. Do you agree with 
> >the
> >asynchronous part at least?
> >
> >>>  2. How do you deal with your MI front end dealing with snapshots of
> >>>  GDB? For example, it has new asynchronous commands, but the MI
> >>>version
> >>>  hasn't been bumped yet.
> >>
> >>There are two kinds of additions, right?  Command return fields, and
> >>async notifications.  In Xcode,
> >>the parser parses everything, and then any command return fields or
> >>async notifications that it doesn't understand, it ignores.  That's
> >>pretty much how the MI was designed, so that the MI can freely ADD
> >>notifications & command return fields, and the UI can just ignore 
> >>them.
> >> The fields are identified by field name, and the notifications by
> >>their notification name.
> >
> >OK, so understood.
> >
> >Commands that add a field will definatly work because the front end
> >ignores them. Commands that loose a field will probably cause a major
> >problem and will be incompatible with the front end.
> >
> >What about when a command changes completly because of a version bump?
> >What about when the commands changes (like N:M breakpoints) and the
> >version is not bumped yet because you have a snapshot of GDB?
> >
> >I need these case's to work because I am not bundled with GDB.
> >
> >So again, I'm asking everyone,
> >
> >1. Can the mainline version get tagged asyncronous commands at the 
> >least?
> >I would prefer every command to have a tag.
> >
> >2. Can there be a discussion about backwards compatibility with MI
> >output commands. This involves several issues I can think of.
> >   1. removing fields from an MI output command
> >   2. changing the output of an MI output command
> >   3. Making the commands themselves be backwards compatible even
> >   between major releases. This essentially makes the MI output version
> >   useless.
> >
> >Thanks,
> >Bob Rossi
> >
> --
> Jim Ingham                                   jingham@apple.com
> Developer Tools
> Apple Computer

Re: MI rules

[Eli Zaretskii]

> Date: Tue, 28 Sep 2004 22:59:59 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: gdb@sources.redhat.com, cagney@redhat.com, ezannoni@redhat.com,
> 	fnasser@redhat.com
> 
> I have one quick note. I would prefer to get some cooperation with the
> MI maintainers. I seriously need this cooperation in order to get
> anything done with CGDB. Also, I consider the work I am doing necessary
> for any front end developer to be able to write a reasonable front end
> without having to heavily patch a version of GDB they distribute with.
> 
> If you consider my goal worthy, please at least respond with some
> reasonable criticism so that these issues can be resolved. I feel that in
> many ways my views on the MI are mostly ignored by the MI maintainers.

Out of those who are marked in MAINTAINERS as "MI maintainers" you can
probably hope to get response only from Andrew, and Andrew has lots of
other responsibilities and things to do.  So I'm not surprised you
feel the way you do.

However, the issues you worry about need not wait for the ``MI
maintainers'' to respond, quite a few (if not most) of them are
general enough to be discussed with all the global maintainers, some
of whom are more responsive.

So I'd suggest to restructure the discussion so that more people could
give you feedback.  Speaking for myself, one of the more significants
reasons that all but prevent my participation in the threads you start
is that messages are very long, mix many different issues, and include
both general concerns, such as MI syntax backwards compatibility, and
low-level details, such as minor grammar optimizations.  (And on top
of that, top-post style makes the messages even longer and harder to
read for someone who, like myself, has only a couple dozen minutes on
a random day to read them.)

So how about if you start several separate threads, one each about a
specific MI issue out of those which are general enough for the global
maintainers to participate?  For example, this list:

> 1. Can the mainline version get tagged asyncronous commands at the least? 
> I would prefer every command to have a tag.
> 
> 2. Can there be a discussion about backwards compatibility with MI
> output commands. This involves several issues I can think of.
>    1. removing fields from an MI output command
>    2. changing the output of an MI output command
>    3. Making the commands themselves be backwards compatible even
>    between major releases. This essentially makes the MI output version
>    useless.

already includes 2 separate issues that don't require too much
MI-specific knowledge for any global maintainer to give you feedback.
If you make the issues visible at the beginning, rather than buried at
an end of a longish message, and keep different issues separate, I
think we will have more hope to come to a consensus enough for you to
craft a patch that has good chances to be accepted.

Re: MI rules

[Bob Rossi]

On Thu, Sep 30, 2004 at 03:23:19PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 28 Sep 2004 22:59:59 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: gdb@sources.redhat.com, cagney@redhat.com, ezannoni@redhat.com,
> > 	fnasser@redhat.com
> > 
> > I have one quick note. I would prefer to get some cooperation with the
> > MI maintainers. I seriously need this cooperation in order to get
> > anything done with CGDB. Also, I consider the work I am doing necessary
> > for any front end developer to be able to write a reasonable front end
> > without having to heavily patch a version of GDB they distribute with.
> > 
> > If you consider my goal worthy, please at least respond with some
> > reasonable criticism so that these issues can be resolved. I feel that in
> > many ways my views on the MI are mostly ignored by the MI maintainers.
> 
> Out of those who are marked in MAINTAINERS as "MI maintainers" you can
> probably hope to get response only from Andrew, and Andrew has lots of
> other responsibilities and things to do.  So I'm not surprised you
> feel the way you do.

I'm glad this is understood. My question is, why do they other
maintainers not "maintain"? Or is responding to the community not
part of being a maintainer?

> However, the issues you worry about need not wait for the ``MI
> maintainers'' to respond, quite a few (if not most) of them are
> general enough to be discussed with all the global maintainers, some
> of whom are more responsive.

OK, I appreciate this advice.

> So I'd suggest to restructure the discussion so that more people could
> give you feedback.  Speaking for myself, one of the more significants
> reasons that all but prevent my participation in the threads you start
> is that messages are very long, mix many different issues, and include
> both general concerns, such as MI syntax backwards compatibility, and
> low-level details, such as minor grammar optimizations.  (And on top
> of that, top-post style makes the messages even longer and harder to
> read for someone who, like myself, has only a couple dozen minutes on
> a random day to read them.)

I appreciate you pointing this out. In retrospect I can see that I am
not bringing up one problem at a time. I will attempt to change this
from here on in. Thanks for the advice.

> So how about if you start several separate threads, one each about a
> specific MI issue out of those which are general enough for the global
> maintainers to participate?  For example, this list:
> 
> > 1. Can the mainline version get tagged asyncronous commands at the least? 
> > I would prefer every command to have a tag.
> > 
> > 2. Can there be a discussion about backwards compatibility with MI
> > output commands. This involves several issues I can think of.
> >    1. removing fields from an MI output command
> >    2. changing the output of an MI output command
> >    3. Making the commands themselves be backwards compatible even
> >    between major releases. This essentially makes the MI output version
> >    useless.
> 
> already includes 2 separate issues that don't require too much
> MI-specific knowledge for any global maintainer to give you feedback.
> If you make the issues visible at the beginning, rather than buried at
> an end of a longish message, and keep different issues separate, I
> think we will have more hope to come to a consensus enough for you to
> craft a patch that has good chances to be accepted.

I will do this. I really appreciate your feedback. It is impossible for
me to self-correct the way I approach the mailing list, I first need to
know that there are problems. Thanks.

Bob Rossi

Re: MI rules

[Andrew Cagney]

FYI,

While I've been very carefully following this thread, I've not yet seen 
a compelling reason to step into the debate.  I think JimI's already 
addressed the issues (thanks), and pointed to where things should go.

Andrew

Re: MI rules

[Bob Rossi]

On Thu, Sep 30, 2004 at 12:35:57PM -0400, Andrew Cagney wrote:
> FYI,
> 
> While I've been very carefully following this thread, I've not yet seen 
> a compelling reason to step into the debate.  I think JimI's already 
> addressed the issues (thanks), and pointed to where things should go.

I still think that we need to add tags to the MI interface, especially
for asynchronous MI output commands ( notifications ). Can this be
discussed with the maintainers and front end developers?

Andrew, you have been the only maintainer that has responded, and I am
grateful for that. However, you simply answer with "no", and I
personally get the impression you are not taking the matters I am
bringing up seriously.

For instance, 

   1. I am bringing up the fact that I need a tag for MI output commands
   that are asynchronous (notifications). I also said that I would prefer 
   to have it for all of them, because then I wouldn't need to play around 
   with the "tokens" at all.

   2. You respond by saying
   "I think others have already responded to this proposal with a clear
   rationale for not making a change."

   3. While I talk to Jim more about it, I find that he has tags in his
   local version of GDB for MI output commands that are asynchronous.
   They do this because they need exactly what I need.

So, two front end developers have independently come across the same
need out of MI. Unfortunately, I don't have the resources to take GDB,
patch it and distribute it with CGDB.

Honestly, I am only interested in making MI better for everyone.
Hopefully we can resolve these issues for the better of GDB. If you
think that this particular feature should not go into GDB, I would
really appreciate to at least be told the way to do what I'm trying to
do with the current MI interface.

Thanks,
Bob Rossi

Re: MI rules

[Jason Molenda]

On Wed, Sep 22, 2004 at 12:18:06PM -0400, Bob Rossi wrote:

> I wasn't being critical at all. Personally, I don't like the fact that
> Eclipse use's a hybrid approach to getting data out of GDB. I have not
> even started adding MI to CGDB because I've been working on GDB,
> bringing it up to the standards I need to get CGDB fully usable by only
> using MI. If others would follow this approach, I'm sure my life would
> have been a lot easier, and CGDB would have been far more along.

For what it's worth, Xcode (the IDE on MacOS X) uses something like
one non-MI command these days ("tty").  It's true that we've done a 
lot of work on the MI side of gdb, but an example of an MI-only
(well, nearly so - there's no bonus points for having 100% MI usage
so we have that one command there) exists and has been shipping for
at least a few years now.  NB Xcode is gratis free, but not libre free, 
i.e. not free software.

J

Re: MI rules

[Alain Magloire]

> 
> On Wed, Sep 22, 2004 at 10:58:34AM -0400, Alain Magloire wrote:
> > > 
> > > 
> > > >I currently have a set of rules that parse an MI output command. This
> > > >includes the flex file, the bison file and an extra source file that
> > > >populates an in memory data structure representing the MI output
> > > >command.
> > > >
> > > >The rules from the documentation had to change only slightly to conform
> > > >to what GDB is actually outputting. The problem is, I haven't tested the 
> > > >parser extensively. The reason for this is because I am waiting to here 
> > > >from the GDB developers how to interpret the data semantically once it 
> > > >is acquired. I believe that every MI output command needs to have a
> > > >header describing what type of MI output command is being transmitted.
> > > >With this knowledge, the front end would understand exactly what
> > > >information it needs to grab from the parse tree. Otherwise, the front
> > > >end gets confusing at best.
> > > 
> > > How are the existing frontends doing it then? Do they just wait after
> > > a sent command until they receive a reply and take it as the one they're
> > > looking for?
> > > 
> > > >BTW, I took a look at the eclipse MI parser, from what I can tell, it
> > > >uses a hybrid MI/CLI approach, and simply parses the MI command with
> > > >string compares. As far as I can tell, this method will be very buggy
> > > >and confusing in the long run.
> > > 
> > 
> > 8-), a very severe criticism.
> > It is a hand written decent parser.  It was simple to write instead of
> > using JavaCC(flex/bison).  The problem is not the parser but
> > the non conformity or rather the lack of feature of the MI Protocol implementation,
> > but that said it should not be seen as a complaint to the GDB folks,
> > MI was a great step in the right direction.
> 
> I wasn't being critical at all. Personally, I don't like the fact that
> Eclipse use's a hybrid approach to getting data out of GDB. I have not
> even started adding MI to CGDB because I've been working on GDB,
> bringing it up to the standards I need to get CGDB fully usable by only
> using MI. If others would follow this approach, I'm sure my life would
> have been a lot easier, and CGDB would have been far more along.
> 

Agreed.

>
...
> 
> Anyways, hope I didn't insult you or the eclipse project,

8-) [[laughs]] none taken ..
speak your mind, I should have put more smileys.

> we are all working on the same side here.
> 

Yes.

Re: MI rules

[Bob Rossi]

On Wed, Sep 22, 2004 at 10:58:34AM -0400, Alain Magloire wrote:
> > 
> > 
> > >I currently have a set of rules that parse an MI output command. This
> > >includes the flex file, the bison file and an extra source file that
> > >populates an in memory data structure representing the MI output
> > >command.
> > >
> > >The rules from the documentation had to change only slightly to conform
> > >to what GDB is actually outputting. The problem is, I haven't tested the 
> > >parser extensively. The reason for this is because I am waiting to here 
> > >from the GDB developers how to interpret the data semantically once it 
> > >is acquired. I believe that every MI output command needs to have a
> > >header describing what type of MI output command is being transmitted.
> > >With this knowledge, the front end would understand exactly what
> > >information it needs to grab from the parse tree. Otherwise, the front
> > >end gets confusing at best.
> > 
> > How are the existing frontends doing it then? Do they just wait after
> > a sent command until they receive a reply and take it as the one they're
> > looking for?
> > 
> > >BTW, I took a look at the eclipse MI parser, from what I can tell, it
> > >uses a hybrid MI/CLI approach, and simply parses the MI command with
> > >string compares. As far as I can tell, this method will be very buggy
> > >and confusing in the long run.
> > 
> 
> 8-), a very severe criticism.
> It is a hand written decent parser.  It was simple to write instead of
> using JavaCC(flex/bison).  The problem is not the parser but
> the non conformity or rather the lack of feature of the MI Protocol implementation,
> but that said it should not be seen as a complaint to the GDB folks,
> MI was a great step in the right direction.

I wasn't being critical at all. Personally, I don't like the fact that
Eclipse use's a hybrid approach to getting data out of GDB. I have not
even started adding MI to CGDB because I've been working on GDB,
bringing it up to the standards I need to get CGDB fully usable by only
using MI. If others would follow this approach, I'm sure my life would
have been a lot easier, and CGDB would have been far more along.

> > >string compares. As far as I can tell, this method will be very buggy
> > >and confusing in the long run.
> 
> I'm not sure on what you base such analysis ... but patches are always
> welcome, it is an open source project.
> And if you have a performing MI parser in Java, please send it to the Eclipse/CDT
> folks, we will be ecstatic.  

This isn't outlandish. You could easily convert the MI parse tree I've
created into XML, and do what you like with it on the Java side.

> > That's why I asked. There are Eclipse, KDevelop and I don't know how
> > many other frontends it's hard to believe they always wrote a new parser.
> > And even if they did was it handwritten or generated... I guess then I'm
> > looking forward to your results :)
> > 
> 
> Eclispe uses the Java language, I suppose KDevelop C++, or other languages.
> Writing a parser, is not the problem, or IMHO is not the problem
> that GDB was trying to solve(You can write a parser for MI within a day).
> Read the followup/feedback posts on the XMI proposals thread.

Anyways, hope I didn't insult you or the eclipse project, we are all working 
on the same side here.

Bobby

Re: MI rules

[Fabian Cenedese]

>> How are the existing frontends doing it then? Do they just wait after
>> a sent command until they receive a reply and take it as the one they're
>> looking for?
>
>Well part of the problem I see is with asyncrhonous MI output commands.

That's the main problem I'd say. If the whole communication was
synchronous you'd exactly know what answer is coming and not
need any labeling.

>How is the front end supposed to understand what the data it just
>recieved was. It doesn't even know what type of mi output command it is. 
>So, after it is parsed and put in a parse tree, I don't see a
>way for the front end to say, "Get the data out of this command that I
>care about". It first needs to understand what type of mi output command
>it just recieved. If it knows that, it can actually walk the parse tree
>to get the data it needs.

I was just wondering what commands you're parsing after looking into
mi/mi-cmds.c. Am I seeing right that over half of the mi commands
are not implemented yet?

>Otherwise if it doesn't know that, you end up in a situation where you
>   1. parse the tree.
>   2. walk the tree to guess what kind of command you just received
>      ( can only imagine what kind of maintenence nightmare this is )
>   3. actually walk the tree to get the data you need, once you know
>      what kind of mi output command you have.
>
>This ends up making the parse walk the tree twice. IMO, GDB already
>knows what kind of MI output command it is sending, so it should just
>tell the front end as part of the mi output command. This would solve
>several problems that I am facing.

Yeah, a simple ^done can come from a lot of commands :)

Thanks

bye  Fabi

Re: MI rules

[Alain Magloire]

> 
> 
> >I currently have a set of rules that parse an MI output command. This
> >includes the flex file, the bison file and an extra source file that
> >populates an in memory data structure representing the MI output
> >command.
> >
> >The rules from the documentation had to change only slightly to conform
> >to what GDB is actually outputting. The problem is, I haven't tested the 
> >parser extensively. The reason for this is because I am waiting to here 
> >from the GDB developers how to interpret the data semantically once it 
> >is acquired. I believe that every MI output command needs to have a
> >header describing what type of MI output command is being transmitted.
> >With this knowledge, the front end would understand exactly what
> >information it needs to grab from the parse tree. Otherwise, the front
> >end gets confusing at best.
> 
> How are the existing frontends doing it then? Do they just wait after
> a sent command until they receive a reply and take it as the one they're
> looking for?
> 
> >BTW, I took a look at the eclipse MI parser, from what I can tell, it
> >uses a hybrid MI/CLI approach, and simply parses the MI command with
> >string compares. As far as I can tell, this method will be very buggy
> >and confusing in the long run.
> 

8-), a very severe criticism.
It is a hand written decent parser.  It was simple to write instead of
using JavaCC(flex/bison).  The problem is not the parser but
the non conformity or rather the lack of feature of the MI Protocol implementation,
but that said it should not be seen as a complaint to the GDB folks,
MI was a great step in the right direction.

> >string compares. As far as I can tell, this method will be very buggy
> >and confusing in the long run.

I'm not sure on what you base such analysis ... but patches are always
welcome, it is an open source project.
And if you have a performing MI parser in Java, please send it to the Eclipse/CDT
folks, we will be ecstatic.  

> That's why I asked. There are Eclipse, KDevelop and I don't know how
> many other frontends it's hard to believe they always wrote a new parser.
> And even if they did was it handwritten or generated... I guess then I'm
> looking forward to your results :)
> 

Eclispe uses the Java language, I suppose KDevelop C++, or other languages.
Writing a parser, is not the problem, or IMHO is not the problem
that GDB was trying to solve(You can write a parser for MI within a day).
Read the followup/feedback posts on the XMI proposals thread.

> bye  Fabi
> 

EOT.

Re: MI rules

[Bob Rossi]

On Wed, Sep 22, 2004 at 04:05:33PM +0200, Fabian Cenedese wrote:
> 
> >I currently have a set of rules that parse an MI output command. This
> >includes the flex file, the bison file and an extra source file that
> >populates an in memory data structure representing the MI output
> >command.
> >
> >The rules from the documentation had to change only slightly to conform
> >to what GDB is actually outputting. The problem is, I haven't tested the 
> >parser extensively. The reason for this is because I am waiting to here 
> >from the GDB developers how to interpret the data semantically once it 
> >is acquired. I believe that every MI output command needs to have a
> >header describing what type of MI output command is being transmitted.
> >With this knowledge, the front end would understand exactly what
> >information it needs to grab from the parse tree. Otherwise, the front
> >end gets confusing at best.
> 
> How are the existing frontends doing it then? Do they just wait after
> a sent command until they receive a reply and take it as the one they're
> looking for?

Well part of the problem I see is with asyncrhonous MI output commands.
How is the front end supposed to understand what the data it just
recieved was. It doesn't even know what type of mi output command it is. 
So, after it is parsed and put in a parse tree, I don't see a
way for the front end to say, "Get the data out of this command that I
care about". It first needs to understand what type of mi output command
it just recieved. If it knows that, it can actually walk the parse tree
to get the data it needs.

Otherwise if it doesn't know that, you end up in a situation where you
   1. parse the tree.
   2. walk the tree to guess what kind of command you just received
      ( can only imagine what kind of maintenence nightmare this is )
   3. actually walk the tree to get the data you need, once you know
      what kind of mi output command you have.

This ends up making the parse walk the tree twice. IMO, GDB already
knows what kind of MI output command it is sending, so it should just
tell the front end as part of the mi output command. This would solve
several problems that I am facing.

Do any of the GDB MI maintainers see this as possible? Please look at
my Email http://sources.redhat.com/ml/gdb/2004-09/msg00173.html

Thanks,
Bob Rossi

Re: MI rules

[Fabian Cenedese]

>I currently have a set of rules that parse an MI output command. This
>includes the flex file, the bison file and an extra source file that
>populates an in memory data structure representing the MI output
>command.
>
>The rules from the documentation had to change only slightly to conform
>to what GDB is actually outputting. The problem is, I haven't tested the 
>parser extensively. The reason for this is because I am waiting to here 
>from the GDB developers how to interpret the data semantically once it 
>is acquired. I believe that every MI output command needs to have a
>header describing what type of MI output command is being transmitted.
>With this knowledge, the front end would understand exactly what
>information it needs to grab from the parse tree. Otherwise, the front
>end gets confusing at best.

How are the existing frontends doing it then? Do they just wait after
a sent command until they receive a reply and take it as the one they're
looking for?

>BTW, I took a look at the eclipse MI parser, from what I can tell, it
>uses a hybrid MI/CLI approach, and simply parses the MI command with
>string compares. As far as I can tell, this method will be very buggy
>and confusing in the long run.

That's why I asked. There are Eclipse, KDevelop and I don't know how
many other frontends it's hard to believe they always wrote a new parser.
And even if they did was it handwritten or generated... I guess then I'm
looking forward to your results :)

bye  Fabi

Re: MI rules

[Bob Rossi]

On Wed, Sep 22, 2004 at 03:38:45PM +0200, Fabian Cenedese wrote:
> Hi
> 
> I know that somebody is writing parser rules for the MI output. How have
> others written their MI parsers if not with rules? Pure string handling/
> comparing etc.? Or are there already some (older) rules which could be
> used for flex/bison?

I currently have a set of rules that parse an MI output command. This
includes the flex file, the bison file and an extra source file that
populates an in memory data structure representing the MI output
command.

The rules from the documentation had to change only slightly to conform
to what GDB is actually outputting. The problem is, I haven't tested the 
parser extensively. The reason for this is because I am waiting to here 
from the GDB developers how to interpret the data semantically once it 
is acquired. I believe that every MI output command needs to have a
header describing what type of MI output command is being transmitted.
With this knowledge, the front end would understand exactly what
information it needs to grab from the parse tree. Otherwise, the front
end gets confusing at best.

BTW, I took a look at the eclipse MI parser, from what I can tell, it
uses a hybrid MI/CLI approach, and simply parses the MI command with
string compares. As far as I can tell, this method will be very buggy
and confusing in the long run.

Thanks,
Bob Rossi

MI rules

[Fabian Cenedese]

Hi

I know that somebody is writing parser rules for the MI output. How have
others written their MI parsers if not with rules? Pure string handling/
comparing etc.? Or are there already some (older) rules which could be
used for flex/bison?

Thanks

bye  Fabi