From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14887 invoked by alias); 12 Mar 2005 14:40:59 -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 14659 invoked from network); 12 Mar 2005 14:40:52 -0000 Received: from unknown (HELO lakermmtao10.cox.net) (68.230.240.29) by sourceware.org with SMTP; 12 Mar 2005 14:40:52 -0000 Received: from white ([68.9.64.121]) by lakermmtao10.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050312144051.VOCN29924.lakermmtao10.cox.net@white>; Sat, 12 Mar 2005 09:40:51 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DA7nS-0004mj-00; Sat, 12 Mar 2005 09:40:54 -0500 Date: Sat, 12 Mar 2005 14:40:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: bpisupat@cs.indiana.edu, gdb@sources.redhat.com Subject: Re: MI starting guide Message-ID: <20050312144054.GA18379@white> Mail-Followup-To: Eli Zaretskii , bpisupat@cs.indiana.edu, gdb@sources.redhat.com References: <20050312000437.GA17327@white> <01c526ee$Blat.v2.4$37bafb40@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c526ee$Blat.v2.4$37bafb40@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00139.txt.bz2 > > AFAIK, FE's use fork/exec with GDB and communicate with it over a pipe > > like you suggested. Beware, some of the MI commands that the manual says > > are there are unimplemented. > > > > If you want to see some interaction between GDB and another process look > > at the gdb.mi testsuite. > > I'm urging people who work with the MI interface, such as Nick and > Bob, to please contribute additions to the manual (either gdb.texinfo > or gdbint.texinfo) that describe what you found out during your work > that you wish has been there to begin with. There is no better source > of useful information than those who actually need it to do some job. > > If you are unsure how or where best to describe what you think is > important, don't hesitate to post your thoughts here and start a > discussion. Thanks to all who originally contributed to the GDB doco, that's why we are even able to talk about this! Honestly Eli, there are so many improvements that we could add, the sky is the limit. In fact, I have several ideas of improving the MI interface doco, of course, none of this will get done if the patch review time issue isn't resolved. - obviously a section on 'asycnronous' MI interface, which I still don't understand the purpose of (since I can't get any of the asynchronous commands to work) - make sure that the documented "example" commands section stay up to date with what GDB actually outputs. I have a funny feeling that many of the commands do not actually output the same info anymore. (we could generate the example data from a testsuite case, and diff what GDB currently outputs to what it is supposed to output to make sure the data doesn't change) - Document what MI commands are implemented/unimplemented - Document the correct MI output command grammar (which is almost correct, but not really) - Somehow document what versions each command was introduced in - A developers howto guide (Although, I think the reference implementation I was talking about would be a better way to describe this) - Document what MI fields are mandatory output for a command, and which ones are optional. I know all of this is a lot of work, but as we move on, I think it would improve the state of affairs a lot. As far as a developers user guide, if GDB had a reference implementation, which I would like to work on, there could be a design guide that goes along with it. This would basically be essential anyways, if my goal of making GDB scriptable via the MI interface is ever going to happen. Personally, I've said this from the beginning. I really don't think anyone should start from scratch, writing an FE on top of GDB/MI. I think GDB should provide a parser, capable of parsing an MI output command, and also an interface to understand the semantics of that parse tree. GDB is the only one who can provide such an interface, and ensure that it is tested in the testsuite, to provide FE's with a quality interface to working with it. Bob Rossi