From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5303 invoked by alias); 19 Sep 2002 19:07:45 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5292 invoked from network); 19 Sep 2002 19:07:44 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 19 Sep 2002 19:07:44 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17s7Zp-0007sY-00; Thu, 19 Sep 2002 15:07:05 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17s6dj-0000PX-00; Thu, 19 Sep 2002 15:07:03 -0400 Date: Thu, 19 Sep 2002 12:07:00 -0000 From: Daniel Jacobowitz To: Scott Moser Cc: Biswapesh Chattopadhyay , GDB List , leiming , Anjuta devel Subject: Re: how to use libgdb ? Message-ID: <20020919190703.GA1494@nevyn.them.org> Mail-Followup-To: Scott Moser , Biswapesh Chattopadhyay , GDB List , leiming , Anjuta devel References: <20020919133221.GA17132@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00279.txt.bz2 On Thu, Sep 19, 2002 at 11:00:37AM -0500, Scott Moser wrote: > On Thu, 19 Sep 2002, Daniel Jacobowitz wrote: > > > On Thu, Sep 19, 2002 at 09:38:40AM +0530, Biswapesh Chattopadhyay wrote: > > > Hi list > > > > > > I'm one of the developers of Anjuta (http://anjuta.sf.net/), an IDE for > > > GNOME. Currently, we are using a spawned subprocess for GDB interaction. > > > This works fairly well, but obviously a shared library with a nice (and > > > reasoinably stable) API would be very helpful for IDE developers. So, my > > > question is: if GDB build process already builds libgdb.a, would any > > > patches to make it build a shared libgdb.so be accepted into the main > > > tree ? It might be very useful, for example, for gnome-debug, which is > > > an upcoming component for debugging applications using a nice GUI > > > interface. This might speed up the responsiveness and enable us to do > > > more advanced stuff (such as tracing multiple threads simultaneously). > > > > They would probably not be accepted - or useful, since we don't plan to > > maintain a stable ABI. What we do maintain is a stable > > machine-parseable interface - MI. See the documentation or list > > archives for more about that if you're not familiar with it. > > While its not my place to say whether or not the patches would be > accepted, I do think they would be at least somewhat useful. > The ABI doesn't need to be stable right away, or even any time in the > near future. But it does seem like some people have an interest in > seeing a libGDB in the short term and for sure in the long term. > I can think of many benefits to moving gdb to a small application > that gains gets all its functionality from a library, but can't think of > many cons. > pros: > allow other projects to use libgdb.so (while they know that it is > not a stable backwards compatible ABI) > performance and functionality gains over the fork and pipe method > for those apps. > through the use of libgdb.so by early adopters, learning what > people would use it for, how they would use it... so that a better > stable ABI *could* be made later. > allow plugins/extensions to gdb to be written in a much more cross > platform manner. > > cons: > implied ABI stability. > > My feeling is that the pros outweigh the cons in this situation. the > implied ABI stability is only *implied*. One suggestion to make sure no > one thinks that you're implying it is would be to just printf inside _init() of > that library with something like the following if the main executable > isn't named gdb: > "This is not a stable ABI. You probably shouldn't be using it unless > you *really* know what you're doing. And even then, maybe you shouldn't > be using it. Also, this code is GPL, if your application uses it, then > it are bound to the terms of the GPL." > > What would it really hurt to have take this step now? Please feel > free add more negitive affects of doing this, maybe I'm just missing > something. The point is that there will never be a stable ABI. Speaking just for myself, I don't want a hack like this that we can never support. We have a machine interface - MI - and it should give you everything you need; if you think communication with GDB has any performance implications, you need to think about it a little more. If you think there are functionality gains from bypassing MI then MI should be extended. For plugins, the right thing to do is to _first_ define an ABI to export to plugins, and then export it portably via (say) a table of function pointers. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer