From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14494 invoked by alias); 7 Mar 2005 02:13:16 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14458 invoked from network); 7 Mar 2005 02:13:09 -0000 Received: from unknown (HELO lakermmtao09.cox.net) (68.230.240.30) by sourceware.org with SMTP; 7 Mar 2005 02:13:09 -0000 Received: from white ([68.9.64.121]) by lakermmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050307021308.QYGM28448.lakermmtao09.cox.net@white> for ; Sun, 6 Mar 2005 21:13:08 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1D87k8-0001iy-00 for ; Sun, 06 Mar 2005 21:13:12 -0500 Date: Mon, 07 Mar 2005 02:13:00 -0000 From: Bob Rossi To: GDB Subject: The future of the MI interface Message-ID: <20050307021312.GA6613@white> Mail-Followup-To: GDB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00068.txt.bz2 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.