From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10793 invoked by alias); 2 May 2008 01:23:31 -0000 Received: (qmail 10784 invoked by uid 22791); 2 May 2008 01:23:30 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 May 2008 01:23:03 +0000 Received: from kahikatea.snap.net.nz (51.63.255.123.dynamic.snap.net.nz [123.255.63.51]) by viper.snap.net.nz (Postfix) with ESMTP id 78C703DA1B1; Fri, 2 May 2008 13:22:56 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 69ECE8FC6D; Fri, 2 May 2008 13:22:53 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18458.27882.797522.892907@kahikatea.snap.net.nz> Date: Fri, 02 May 2008 01:23:00 -0000 To: Vladimir Prus Cc: Pawel Piech , gdb@sources.redhat.com Subject: Evolution of GDB/MI [was Re: MI non-stop interface details] In-Reply-To: <200805012211.51656.vladimir@codesourcery.com> References: <200804261939.37635.vladimir@codesourcery.com> <200805012059.50679.vladimir@codesourcery.com> <481A0340.7050801@windriver.com> <200805012211.51656.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.2.50.2 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00021.txt.bz2 > > Through its many > > versions GDB has freely changed (or "cleaned up") the MI protocol in > > subtle ways without warning (e.g. adding quotes around the condition > > parameter in -break-condition). This creates headaches for clients, and > > can ultimately make the client code difficult to maintain. A perfect > > example of this is the CDI-GDB Eclipse integration. While it has other > > architectural issues, the myriad of workarounds for various GDB versions > > in it makes it difficult to know whether a change for latest GDB version > > won't break support for old GDB versions. What I don't think GDB > > maintainers realize is that ultimately this policy does a lot of harm to > > GDB adoption and GDB's reputation in the larger community. I don't think it's a question of awareness. Maintaining backward compatibility is extra work for GDB developers while finding workarounds for different versions is extra work for frontend developers. While the former group tries to consider the latter (united we stand, divided we fall) I think frontend developers really need to take an active part in Gdb development if they expect any kind of smooth ride. Up till now, that has not really been the case for Eclipse, although recently it does appear to be changing. > > I would > > guess that most users of GDB have some kind of graphical interface and > > their quality is linked to perception of quality of GDB. GDB/MI is a > > published protocol with many users, and I wish that this fact had more > > significance to its maintainers. > GDB/MI is actually not a finished published protocol -- it's work in > progress. Unfortunately, frontend maintainers tended to read between the > lines, and guess the behaviour and accepted input instead of asking > here. And in cases where what they've read between the lines does not > correspond to what GDB developers means, the result is a buggy frontend :-) Well, it's described in the manual, so I guess it is published in that sense. We have attempted to describe how GDB/MI might reasonably change in the future. Perhaps now is the time to expand on that part of the documentation. -- Nick http://www.inet.net.nz/~nickrob