The future of the MI interface

[Bob Rossi <bob at brasko dot net>]

Hi,

Lately I've been complaining about the GDB patch review process,
as it is applied to the patches I post for the MI interface. I've
complained about the time it takes to get patches into GDB.

I feel that I owe everyone an explanation of the amount of work that I
have planned to get into GDB, so that on record there will be an account
of what I actually trying to accomplish. For this reason, people will
understand why I am interested in syntax checking the testsuite, and
what I have planed next.

Please forgive me for the poor wording of my plans below, as I wrote
them up rather quickly.

Thanks,
Bob Rossi 

Plans for MI interface

1. MI Output Commands

This is mostly outside of the GDB executable. The parse tree and semantical 
analysis will be created and used in the testsuite and by other applications 
as they see fit.

1.1 Syntax Analysis

  - fix doco for MI output grammar (grammar in doco is slightly incorrect)
  - Generate parser that can parse a single MI output command and create
    a parse tree
  - Use the parser to validate the MI output command syntax in the testsuite.
    This does not require much re-writing of the test case's.

1.2 Data Structures and Semantics Analysis

  - Determine what kind of MI output command the parse tree represents.
    I believe this needs to be done without having knowledge of the MI input
    command that triggered the MI output command. For instance, The command 
    should describe what kind of message it is as a header of some sort, 
    instead of having the TOKEN field. Also, it's impossible to determine 
    what type of asynchronous command has just been received without walking 
    the parse tree to guess. It should be simple and deterministic to figure 
    this out in all case's.
  - After knowing what type of MI output command the syntax tree represents,
    populate a C data structure, specific to that command.
  - Create an Tcl extension that will translate an MI output command into a 
    Tcl data structure. Since the C data structure will already be around, 
    simply translating that structure to Tcl will be all that's required.
  - The testsuite commands can be re-written. An MI input command can be sent 
    and the Tcl extension can create a data structure representing the MI 
    output command. Tests will use the data structures, instead of regex's. 
    With this data structure, do semantical analysis in the testsuite. This 
    could range from validating that certain fields are in the structure, to 
    validating the contents of the data structure.

1.3 Portability

  - Allow the C data structures to be easily ported to other languages. This 
    could simply be an interface that translates the C data structures 
    directly to other languages like Tcl, or Perl. It could also be that the 
    data structure know how to transmit themselves as XML, so languages like 
    Java don't have to have binding's with the actual interface.
  - A first step would be to have the Data available in both C and Tcl.

1.4 Documentation
  - Allow for doco generation for these data structures. In this way, there 
    could be a developers guide to the MI interface. Each field will have to 
    be documented and describe if the data has to be there, or simply might 
    be there.

2. MI Input Commands

This will be linked in and used by GDB itself. It will allow GDB to parse and 
use data structures for MI input commands.

2.1 Syntax Analysis

  - fix doco for MI input commands (grammar could be incorrect)
  - Generate parser that can parse a single MI input command and create a 
    parse tree
  - put the parse tree inside GDB, to make sure that the commands that it is
    getting are of the correct syntax

2.2 Data Structures and Semantics Analysis
	
  - Populate a data structure internally to GDB that will allow it to process 
    a command.
  - GDB can look at the data structure and determine if the input is 
    sufficient to process a command.

3. Thin client layer

3.1 Client interface

  - Overall, the interface will be *simple*, and the basic unit needed
  - Possibly write an interface that allows a user to create an MI input 
    command without using strings. They can call a function with some 
    arguments and the proper MI input command is created.
  - Write an interface, that allows an application to send an MI input command
    and get back an MI output data structure.
  - Possibly have this interface by responsible for starting GDB with a pty 
    between it and the application.
  - The interface could have several functions for creating an MI input 
    command, and several data structures that represent the MI output command.
  - The interface could take care of queuing of commands.

3.2 Scripting & Testsuite

  - Use TCL as an example language to script GDB using this interface
  - If we get this far, the testsuite can then be re-written using the 
    scripting interface to GDB, instead of using Expect to gather and queue 
    the MI output commands.

4. Reference Implementation

  - Write a curses based interface to the GNU debugger similar to CGDB. This 
    will use the new library created and get the work of the TUI off of the GDB
    developers, so they can better spend there time on the debugger, instead of
    it's interface.

  - It will be a reference implementation that uses the data structures that 
    are tested in GDB and are known to work. This will increase the stability 
    and quality of front end's to GDB.