From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6976 invoked by alias); 27 Jan 2006 17:16:44 -0000 Received: (qmail 6967 invoked by uid 22791); 27 Jan 2006 17:16:44 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao04.cox.net (HELO eastrmmtao04.cox.net) (68.230.240.35) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jan 2006 17:16:42 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060127171636.TDNW19943.eastrmmtao04.cox.net@localhost.localdomain>; Fri, 27 Jan 2006 12:16:36 -0500 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1F2XDp-0000nE-39; Fri, 27 Jan 2006 12:17:17 -0500 Date: Fri, 27 Jan 2006 17:53:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI -break-info command issues Message-ID: <20060127171717.GD30826@brasko.net> Mail-Followup-To: Eli Zaretskii , Vladimir Prus , gdb@sources.redhat.com References: <200601271115.22939.ghost@cs.msu.su> <20060127151220.GA978@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00308.txt.bz2 On Fri, Jan 27, 2006 at 07:10:54PM +0200, Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Fri, 27 Jan 2006 18:47:47 +0300 > > > > > _Extending_ MI is fine; it was designed to be extensible. _Removing_ > > > fields from MI is not fine, because you don't know if some other > > > frontend relies on the data that you find superfluous. > > > > > > Folks have said this at least twice in this thread already. If you > > > disagree, could you say why? > > > > Because with those fields, you get new issues: > > > > 1. They are not documented in sufficient detail. > > The truth is, _nothing_ in GDB/MI is documented in sufficient detail. > We are lucky to have any documentation at all. > > Historically, GDB/MI was added to the sources without _any_ > documentation. I needed to lobby those who wrote the code to make > some docs available, and finally got a kind of white paper that > described what MI _will_ look like; it goes without saying that the > reality was quite different. I then needed to edit that document > heavily to make it fit into the manual (convert chapters to sections, > sections to subsections, fix style and Texinfo usage, etc.) and that > is what we have now, basically, except that some portions were > improved since then, whenever commands were added/changed. Eli, one thought I had recently was this. I would like to automate the examples, using the testsuite. So that if an MI output command changed, the sample would be updated. Do you think this would be possible to do? I find the documentation get's quickly out of date with what GDB is actually outputting. We could add a new test case, which would get the mi output commands we are interested in, and put them in the tex file somehow. What do you think? Sounds ambitious, I know. Bob Rossi