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: MI rules


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



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