From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13622 invoked by alias); 19 Sep 2002 16:02:23 -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 13614 invoked from network); 19 Sep 2002 16:02:22 -0000 Received: from unknown (HELO e1.ny.us.ibm.com) (32.97.182.101) by sources.redhat.com with SMTP; 19 Sep 2002 16:02:22 -0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8JG0iAK098968; Thu, 19 Sep 2002 12:00:44 -0400 Received: from dmfet (dmfet.austin.ibm.com [9.53.216.34]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8JG0b7S118164; Thu, 19 Sep 2002 12:00:37 -0400 Received: from smoser (helo=localhost) by dmfet with local-esmtp (Exim 3.35 #1 (Debian)) id 17s3jJ-0006zi-00; Thu, 19 Sep 2002 11:00:37 -0500 Date: Thu, 19 Sep 2002 09:02:00 -0000 From: Scott Moser X-X-Sender: smoser@dmfet To: Daniel Jacobowitz cc: Biswapesh Chattopadhyay , GDB List , leiming , Anjuta devel Subject: Re: how to use libgdb ? In-Reply-To: <20020919133221.GA17132@nevyn.them.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-09/txt/msg00276.txt.bz2 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. Scott Moser Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-1533 T/L: 678-1533 ssmoser@us.ibm.com , internal zip: 9812