From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9461 invoked by alias); 18 Apr 2014 17:59:57 -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 9452 invoked by uid 89); 18 Apr 2014 17:59:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-pb0-f41.google.com Received: from mail-pb0-f41.google.com (HELO mail-pb0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 18 Apr 2014 17:59:55 +0000 Received: by mail-pb0-f41.google.com with SMTP id jt11so1689923pbb.0 for ; Fri, 18 Apr 2014 10:59:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=aNvBKZ7ngQ5+QmChz8H3ko9Gizw2p2kWzMSIDCo1NCw=; b=i5Pi4Vk77Euez3JzYdwjVAB2YRIfIl3Ws16cc/UK088JWJlCLtVwBjQwJmkXrgvonw icHiQE2E4pbRblRaTKNADe50yyjnYAtuVhNi6c6bt2I1ydJJD1q6wDjbOUjxtFXF+Oo/ tN4GdNmiSS/GH8h3LrMR+8l9fVXlXIS/FR38WmzSi+WP+AGAdLkW4H9SrRR/KHN0TAa2 il06Is52m5CQLoeqgPpD5fD6v406LnnYH2bBypKyNZ/XV1AUfQNaVDGIdajwNIHzRDrh Y+1Kbzjp8V4K3MZemiH3d8XS2rMURqUdMSMP3hO0DoElL+V6w7RtTI+FcHGYyrrLy8Qw p24w== X-Gm-Message-State: ALoCoQkUVgRfaidRucXMYRfMsfI0aFjPSYdI5H5stPU3sTC00mYxMnC5w6Qr0gbknG9+iyR0lYRA X-Received: by 10.68.215.40 with SMTP id of8mr23281405pbc.15.1397843993713; Fri, 18 Apr 2014 10:59:53 -0700 (PDT) Received: from linux (ip68-9-64-242.ri.ri.cox.net. [68.9.64.242]) by mx.google.com with ESMTPSA id vo1sm144668474pab.32.2014.04.18.10.59.52 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 18 Apr 2014 10:59:52 -0700 (PDT) Date: Fri, 18 Apr 2014 19:27:00 -0000 From: Bob Rossi To: Vladimir Prus Cc: Andrew Burgess , gdb@sourceware.org Subject: Re: MI async status output Message-ID: <20140418175958.GA31328@linux> 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> <535155F9.3030405@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535155F9.3030405@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00063.txt.bz2 On Fri, Apr 18, 2014 at 08:42:33PM +0400, Vladimir Prus wrote: > 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. I think I spelled that out pretty clearly. The library providing the API solves the problem, so that every implementation doesn't have to. > >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. But now all N front ends need to be modified to handle mi1, mi2 or json. > 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. Agreed. I plan on wrapping gdbwire with swig to provide python api's. In the short term, you might see some emails for me, asking about specific oddities in the GDB/MI protocol. This will be an an effort to provide a robust API. In the long term, we'll see how many edge case's there really are and perhaps decide where to go from there. Thanks! Bob Rossi