From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26527 invoked by alias); 13 May 2006 15:46:48 -0000 Received: (qmail 26506 invoked by uid 22791); 13 May 2006 15:46:47 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 13 May 2006 15:46:46 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FewK7-0001Ii-Lp; Sat, 13 May 2006 11:46:31 -0400 Date: Sat, 13 May 2006 16:04:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Bob Rossi , Eli Zaretskii , ghost@cs.msu.su, gdb-patches@sources.redhat.com Subject: Re: CLI and GDB/MI documentation patch Message-ID: <20060513154631.GA4941@nevyn.them.org> Mail-Followup-To: Nick Roberts , Bob Rossi , Eli Zaretskii , ghost@cs.msu.su, gdb-patches@sources.redhat.com References: <17509.54397.736467.479414@kahikatea.snap.net.nz> <17509.943.40875.198555@farnswood.snap.net.nz> <20060512221531.GA1741@brasko.net> <17510.62256.102468.268003@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17510.62256.102468.268003@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00296.txt.bz2 On Sun, May 14, 2006 at 09:06:56PM +1200, Nick Roberts wrote: > AFAICS the only changes to MI since 6.4 have been to add the fullname field > to breakpoint related commands and to generate an error record for directly > entered CLI commands. I think we only need to bump the number when an > incompatible change change is made that will break existing front ends. Right. I have at least one such change in mind - I posted about the mess of quoting and backslash processing on gdb@ some time ago though I have no idea when I'll have time to get back to it. The asynchronous changes you've been working with may also require an MI level bump. > break with the new level). We did start to talk about what changes could be > made within one level: new commands, extra fields etc which I think we need to > document so that developers know what to expect. I think at some stage we > should also document our thoughts changing MI level. I invite you :-) -- Daniel Jacobowitz CodeSourcery