From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29749 invoked by alias); 2 Dec 2005 19:23:23 -0000 Received: (qmail 29741 invoked by uid 22791); 2 Dec 2005 19:23:22 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 02 Dec 2005 19:23:20 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EiGV2-0003cX-7C; Fri, 02 Dec 2005 14:23:16 -0500 Date: Fri, 02 Dec 2005 19:23:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Andrew STUBBS , gdb@sourceware.org Subject: Re: [RFC] plugin/extension interface Message-ID: <20051202192316.GA13606@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Andrew STUBBS , gdb@sourceware.org References: <439090FE.8040502@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00008.txt.bz2 On Fri, Dec 02, 2005 at 08:48:58PM +0200, Eli Zaretskii wrote: > > Date: Fri, 02 Dec 2005 18:22:54 +0000 > > From: Andrew STUBBS > > > > I would like to test the waters and find out what your opinion would be > > on the subject of a GDB plugin/extension interface. > > Such suggestions (not only for GDB, for other GNU projects as well) > are usually rejected by Richard Stallman and the FSF, because they > make it possible to add to GDB significant new features with > proprietary (i.e. non-free software) shared libraries, thus avoiding > the need to release any parts of GDB under GPL. I think we could discuss this with the FSF, if we had sufficiently compelling reasons. But, I don't think that we do, right now. Andrew, I can't support an interface like the one you've described. GDB is a hugely complicated program, with many independent areas; it's not clear to me which of those areas you're trying to make pluggable. It looks to me like it is specifically the target interface - just a very small piece of the pie. Also, new CLI commands. If that's right, the traditional solution to the target interface is a third party program which acts as a conversion tool between the GDB remote protocol and your proprietary target protocol, with whatever glue logic you would otherwise put into the plugin. The remote protocol serves as the boundary interface in the same way that the DLL boundary would serve as an interface. If what you want can't be done that way because of shortcomings in the protocol, we can fix them. This keeps the already-existing, documented, and supported remote protocol as the extent of GDB's obligation to remote targets. All the other bits you wanted to export as methods have less clear semantics, and some of them are guaranteed to change over time. GDB is burdened already with support for a huge number of targets using the _one_ interface; I don't want to deal with backwards compatibility. For new CLI commands, the right answer is probably to implement them in-core in some scripting language, and optionally pass things back to your remote target via "monitor" commands. The existing scripting language is inadequate. You can find preliminary (but usable) perl bindings in the mailing list archive. I've hacked Guile into GDB in the past, and when I can find some time, I intend to revisit the general problem (probably using Python, this time, since I'm most familiar with it at the moment). This requires some MI interface surgery and is not a small task. -- Daniel Jacobowitz CodeSourcery, LLC