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.