From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19984 invoked by alias); 6 Nov 2002 23:07:36 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19977 invoked from network); 6 Nov 2002 23:07:35 -0000 Received: from unknown (HELO e2.ny.us.ibm.com) (32.97.182.102) by sources.redhat.com with SMTP; 6 Nov 2002 23:07:35 -0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA6N7NgI027674; Wed, 6 Nov 2002 18:07:23 -0500 Received: from localhost.localdomain (pclarke.austin.ibm.com [9.53.216.242]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA6N7L5G160328; Wed, 6 Nov 2002 18:07:21 -0500 Subject: Re: [PATCH] plugin patch From: "Paul A. Clarke" To: Andrew Cagney Cc: Scott Moser , Jelmer Vernooij , Eli Zaretskii , gdb-patches@sources.redhat.com In-Reply-To: <3DC94DD8.10009@redhat.com> References: <20021106145415.GA2350@charis.vernstok> <20021106155151.GA2522@charis.vernstok> <3DC94DD8.10009@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 06 Nov 2002 15:07:00 -0000 Message-Id: <1036623919.539.145.camel@pclarke> Mime-Version: 1.0 X-SW-Source: 2002-11/txt/msg00143.txt.bz2 ...a bit long, sorry... On Wed, 2002-11-06 at 11:14, Andrew Cagney wrote: > > Plugins won't "know" the API that is used in newer versions of GDB, so > > they can't really decide whether they are or are not compatible with > > it. Only allowing plugins to be loaded with _exactly_ the same version > > as the gdb they are loaded into works well (same way the linux kernel > > does). > [...] A plug-in architecture only works when there > is a stable published interface and GDB's current internal interfaces > and mechanisms are about as far from `stable' and `published' as you can > get :-/ > > Accepting this patch will create a situtation (actually very like the > Linux kernel) where either: > - The plug-in developers play constant catch-up with GDB's evolving > interfaces - every new release will require new plug-in. > - GDB's development stagnates because the plug-in developers depand the > specification and support of an additional external interface (over and > above MI(2)). I agree that the above cons are reasonable expectations, but it would seem the same issues would arise regardless if the code is a plug-in or just code which is bolted on and rebuilt every time. The maintenance issues are the same. Indeed, if some bolted-on code is pulled into the GDB base, then the GDB team become obligated to either maintain it enough to get a successful build, or remove it entirely. At least with a plug-in, the maintenance of the plug-in is the responsibility of the maintainter of the plug-in, not the GDB team. Additionally, if the plug-in is considered generally useful, it could always be pulled into the GDB base at any time (assuming copyright ass't.), since we believe all GDB plug-ins would necessarily be GPL'd. The pros, then: - maintenance of plug-in (playing catch-up) is the responsibility of the plug-in maintainer, not the GDB team - maintains code size of base GDB - allows potentially large optional features without bloating GDB - allows extensibility without requiring GDB source downloads, builds, or frequent relinks - arguably encourages innovation by allowing more flexibility in working with and enhancing GDB - the enabling patch itself is very small and isolated The biggest con, then, is the lack of a stable interface. As you say, this is also a con for the Linux kernel. However, it would be no worse than the Linux kernel, and one could argue that the benefits with respect to innovation far outweigh revisting a decision to allow them (kernel modules) in the first place. If there is any way to make the plug-in capability more palatable, we can make those changes. Perhaps each time a plug-in is loaded, a warning is displayed, like "Plug-ins are not officially supported, so please report *any* problems to the plug-in maintainer", and encourage the plug-ins to advertise a maintainer URL. Maybe instead of "plug-ins", from which some might infer a stable plug-in API, we should use the term "modules", with similar non-guarantees of API stability as with the Linux kernel?? :-) > With regard to the modules that IBM and other vendors are planning on > writing, can I encourage you to contribute them to the FSF? That way, > the entire Free Software Community would benefit (and this plug-in issue > would be mute :-). Absolutely, any plug-ins developed for GDB should and will be GPL'd. > GDB's internals are undergoing massive change(1) and the various GDB > interfaces reflect this. > (1) Don't believe me? I'm currently commiting patches that eliminates > registers[] from the core of GDB. That interface, for too many many > years, formed part of the foundation on which GDB was built. This would seem at least in part to conflict with later comment: > GDB's current architecture allows the relatively easy addition of new > components (a new language, a new remote backend, a new isa) - add the > file to the source list and re-compile. In theory, you don't need to go > around modifying lots of headers and the like. > > This is simply ``good design''. If it is easy to add new components, would it be so hard to maintain a plug-in? > (2) A long term MI objective is to define a set of interfaces that both > MI and the CLI can use. FernandoN made reference to this in responce to > your original post. That's interesting, and I haven't heard about this before. It sounds like these interfaces would then also be good candidates for a plug-in interface. Would you agree? Maybe we could help? Just as an example, using Scott's plug-in enabling patch, I created a plug-in which detects memory leaks and bad calls to free (any address not previously returned by an allocation function). (I'd be happy to share it with the list if anyone is interested.) One can enable/suspend/resume/disable the detection logic at any time, and a full report, including full backtraces is available. This example is not large enough or niche enough to be a good example of why plug-ins are a Good Thing, but one can easily see a similar plugin with library-specific (e.g. libgtk, libqt, etc.) functionality that probably wouldn't make sense to integrate directly into GDB. Such a plug-in could potentially be very large as well. It's impractical to write something that sends commands to gdb over a pipe for each such case where a plug-in would be useful, especially if you need more than one similar case active simultaneously; it's not acceptable to tell customers to go download GDB, apply a patch, and build in order to get some neat functionality; and it's not reasonable to expect that all potential plug-ins are good candidates for inclusion in the GDB base. Let each plug-in maintainer handle that work. As you said, "there is always more work to do." :) Regards, Paul Clarke