MI output commands and backwards compatibility

[Bob Rossi <bob at brasko dot net>]

Hi,

As you know, I've been working on a parser for the MI output commands.
This seems to be going very well, and hopefully, after it has been
tested for a while, I've proposed using it to validate the output of the
GDB in the testsuite.

However, I have run into several other questions now that I have broken
up GDB's MI output command into a higher level. For the sake of this
Email I will refer to the "higher level" as a "parse tree" or PT.

For example, I have basically broken up two possible ways to understand
GDB's MI output commands. They are,
   1. The front end must know what command it issued, 
   	  therefore knowing what MI output command was sent back, 
	  and then it is capable of walking the parse tree to get the data
	  it needs.
   2. The front end has a parse tree, and it must look at the data in the
      parse tree to figure out what type of MI output command was sent by
	  GDB. After it figures out what type of command it received, it 
	  can then move into the case above.
   
The first rule is necessary because two MI output commands could have the 
exact same syntax, and therefor create the same PT. When a front end goes to
walk the PT, it can not figure out just from the PT what the data is   
referring to, or what to do with the data. Because of
this problem it is only possible for the front end to understand what
the parse tree represents by knowing what MI output command generated the
parse tree. ( I know that using the [token] in the grammar mostly solves
this problem )

Also, the second situation is where it gets more confusing. This happens
with asynchronous commands are sent from GDB to the front end. Since the
front end didn't ask for anything it has no idea what command it just
received. Looking at the parse tree is the only way it can figure out
what command GDB just sent it. Unfortunately, it is possible that the
front end has to look pretty deep into the PT to actually determine what
kind of output command was just received. Also, because MI output commands 
could potentially have the same output, in certain circumstances, it would 
be impossible to determine the type of MI output command that is being
received just by looking at the parse tree. Remember the front end must
first know what kind of command it is receiving before it can make any
sense out of the command. In short, once you figure out what type of 
MI output command you just received, if this is possible, you can then 
move up to case #1 and walk the PT to get the data that you need.

I have a solution to this problem, that I think will also satisfy the 
requirements for backwards compatibility. I originally proposed that 
every MI output command should be backwards compatible, otherwise, if 
this can not be done, a new MI output command is created to take the 
place of the old one. To do this, we can prefix the MI output
syntax to have a unique label, representing the type of output command
that was just sent. So, the top level grammar could change from
	output => ( out-of-band-record )* [ result-record ] "(gdb)" nl
to
	output => label ( out-of-band-record )* [ result-record ] "(gdb)" nl
	label  => label "=" cstring

With this information, once a front end was programmed to handle a 
certain MI output command ( label ), it will always be able to handle 
that MI output command. Also, snapshots of GDB between major releases 
will also not be a problem.

If this would be acceptable, I would happily come up with a patch to
make this change. To recap, this solution would solve 2 problems,
	- The ability for front ends to have backwards compatibility with
	  MI output commands.
	- The ability of the front end to understand which MI output command 
	  it is walking, in order to semantically understand what to do with 
	  the data.

Finally, this solution only effects the MI output commands. The 
MI input commands are not addressed here.

Thanks,
Bob Rossi