From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6601 invoked by alias); 27 Jan 2006 15:48:20 -0000 Received: (qmail 6592 invoked by uid 22791); 27 Jan 2006 15:48:20 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jan 2006 15:48:17 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1F2VpK-0003qO-7n for gdb@sources.redhat.com; Fri, 27 Jan 2006 16:47:54 +0100 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jan 2006 16:47:54 +0100 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jan 2006 16:47:54 +0100 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI -break-info command issues Date: Fri, 27 Jan 2006 15:51:00 -0000 Message-ID: References: <200601271115.22939.ghost@cs.msu.su> <20060127151220.GA978@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 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/msg00297.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Jan 27, 2006 at 05:59:56PM +0300, Vladimir Prus wrote: >> If "minimal" protocol is explicitly not a goal of MI, or changing MI is >> prohibited, just say so and I'll stop asking why there are unnecessary >> fields. > > _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. 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. 3. Everybody using MI should decide if those fields are useful for him, or not. 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. - Volodya