From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10714 invoked by alias); 18 Apr 2014 16:42:44 -0000 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 Received: (qmail 10701 invoked by uid 89); 18 Apr 2014 16:42:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Apr 2014 16:42:42 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1WbBs6-000606-Bh from Vladimir_Prus@mentor.com ; Fri, 18 Apr 2014 09:42:38 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Apr 2014 09:42:37 -0700 Received: from [172.30.88.157] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Fri, 18 Apr 2014 17:42:36 +0100 Message-ID: <535155F9.3030405@codesourcery.com> Date: Fri, 18 Apr 2014 17:59:00 -0000 From: Vladimir Prus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Bob Rossi CC: Andrew Burgess , Subject: Re: MI async status output References: <20140409210803.GA3166@linux> <5346B226.40209@cs.msu.su> <20140410201259.GA15060@linux> <5347BD84.5030200@broadcom.com> <20140412002538.GA27657@linux> <5350E049.9070705@codesourcery.com> <20140418104619.GA26892@linux> <53512470.8080305@codesourcery.com> <20140418163002.GA29631@linux> In-Reply-To: <20140418163002.GA29631@linux> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00062.txt.bz2 On 18.04.2014 20:30, Bob Rossi wrote: >> Though quite possibly, MI3 should just accept and produce JSON. > I think it would be good to have an honest discussion on this topic. > > It was really easy to write CGDB based on GDB annotations. The obvious > problem was that the annotations interface provides very little > information. So CGDB is very limited. > > In steps GDB/MI. > - The GDB/MI grammar is wrong (fix it and you hit the semantic issues) > - When GDB changes, how do the front ends handle the before and after? > Problem: A 1 (GDB) to many (front end) relationship exists making it > difficult to change or improve GDB. > - How do front ends work with different versions of GDB? > Problem: A 1 (front end) to many (GDB versions) relationship exists > making it difficult for a front end to work well with any version of > GDB. Front ends naturally suffer from a least common demoninator > feature set. That is, only use the features available in most > versions of GDB. > > The solution to these problems is pretty clear, lets give developers an API. I am not sure what's different between "API" and GDB/MI, which is also an API or some sort. No matter what a new API might be, the problems of GDB changes and supporting multiple versions of GDB will be the same, except for wrong grammar. Web developers have the same problems with API changes, for all I know. > Now front ends share the benefits of a common api, rather than every > front end dealing uniquely with all these issues, which is unrealistic. > > Now GDB can change independent of the protocol. GDB can look at what > features it is affecting in the API while developing it's internal features. > It's a win win situation. > > The API doesn't have to be internal to GDB. It could be gdbwire, a layer > that sits on top of GDB. That's the goal I'm pursuing in my spare time > for CGDB. > > However, based on your comments about JSON, and the fact that the python > api is the latest development in automating GDB, I'm not even sure how > appropriate it is to write a front end on GDB using MI. Can anyone speak > to the long term viability of this protocol? I'd hate to port CGDB to > GDB/MI only to be told that it's been superseded by a new protocol. > http://www.cygwin.com/ml/gdb/2003-02/msg00070.html I mention JSON in part because GDB/MI grammar is rather similar to it already. Saying "it's just JSON" would mean GDB folks don't have to deal with insignificant syntax matters. Also, it would make it rather easy to add a Python function callable by frontend that would output data frontend can parse - using JSON support in Python is way easier than Python binding for GDB ui_ machinery. - Volodya -- Vladimir Prus CodeSourcery / Mentor Graphics http://www.mentor.com/embedded-software/