From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3455 invoked by alias); 27 Jan 2006 17:11:31 -0000 Received: (qmail 3446 invoked by uid 22791); 27 Jan 2006 17:11:30 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jan 2006 17:11:29 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HRW06311; Fri, 27 Jan 2006 19:10:50 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-83-130-255-5.inter.net.il [83.130.255.5]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id COV28274 (AUTH halo1); Fri, 27 Jan 2006 19:10:48 +0200 (IST) Date: Fri, 27 Jan 2006 17:16:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb@sources.redhat.com In-reply-to: (message from Vladimir Prus on Fri, 27 Jan 2006 18:47:47 +0300) Subject: Re: MI -break-info command issues Reply-to: Eli Zaretskii References: <200601271115.22939.ghost@cs.msu.su> <20060127151220.GA978@nevyn.them.org> X-IsSubscribed: yes 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/msg00306.txt.bz2 > 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. I will personally applaud anyone who submits improvements to the MI docs. > 2. Looking at 'mi-read-memory.exp', those fields don't appear to be tested > -- it's only checked that the values of the fields are in hex. I'm sure we will happily accept patches to the test suite as well. > 3. Everybody using MI should decide if those fields are useful for him, or > not. If you have ideas how to improve this aspect (without hurting generality), please consider sharing them. > The problem with existing frontends can probably be solved by posting a > prominent message to mailing list whenever MI output is going to change. Or > using versioning. The latter possibility was discussed in some length several months ago, and I think we have now a mechanism to do this.