This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
The future of the MI interface
- From: Bob Rossi <bob at brasko dot net>
- To: GDB <gdb at sources dot redhat dot com>
- Date: Sun, 6 Mar 2005 21:13:12 -0500
- Subject: The future of the MI interface
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.