From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8504 invoked by alias); 2 Dec 2005 23:07:36 -0000 Received: (qmail 8495 invoked by uid 22791); 2 Dec 2005 23:07:35 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.203) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Dec 2005 23:07:31 +0000 Received: by zproxy.gmail.com with SMTP id x3so271272nzd for ; Fri, 02 Dec 2005 15:07:29 -0800 (PST) Received: by 10.36.220.33 with SMTP id s33mr3151200nzg; Fri, 02 Dec 2005 15:07:29 -0800 (PST) Received: by 10.37.2.6 with HTTP; Fri, 2 Dec 2005 15:07:29 -0800 (PST) Message-ID: <8f2776cb0512021507m52b9d491gd4ddc0ceaab594ba@mail.gmail.com> Date: Fri, 02 Dec 2005 23:07:00 -0000 From: Jim Blandy To: Mark Kettenis Subject: Re: [RFC] plugin/extension interface Cc: gdb@sourceware.org In-Reply-To: <200512022241.jB2Mf3Fk024314@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <439090FE.8040502@st.com> <200512021936.jB2JaZ6n014666@elgar.sibelius.xs4all.nl> <8f2776cb0512021412n17d2a8b2rf8cb4a48daa9449e@mail.gmail.com> <200512022241.jB2Mf3Fk024314@elgar.sibelius.xs4all.nl> 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/msg00013.txt.bz2 On 12/2/05, Mark Kettenis wrote: > I really doubt that. Short term it'd only increase the load since we > have to build the plug-in interface. Long term, we still have to > maintain that interface. We'll also get lots of support questions > where the problems are really with the third party plugins, but where > the bug reporter conveniently forgets to mention that he's using a > third party plugin. Let's keep people out of our address space if > they don't want to commit themselves to providing sources and manpower > to maintain those sources. I don't think you're seeing the potential here. There are a *lot* of things people would like to do with debuggers: it's one of the best fields for productive creeping featurism you can imagine. Writ broad, a debugger is a program for watching your program run. That's open to so much application-specific interpretation it's actually hard to imagine how generic code (like GDB) would even be useful, if you haven't seen it in action. In other words, if the plug-ins had enough hooks to customize GDB's behavior (printing values, or decoding the stack, say), I think you'd be really surprised what people would do with it. They'd do tons of stuff that we'd never want to include in the core distribution, but which would add enormous value to GDB for their problems. And of course, there would be a few that we'd want to incorporate. To take another tack: plug-ins were vital to Apache's success. Why wouldn't they have the same effect on GDB? The only qualification I'd make here is that GDB's current internal organization isn't very friendly to this kind of stuff. A plug-in interface that could engender the kind of stuff I'm describing would have to be pretty clean, high-level, and documented. I could certainly see the argument that it's too much work to bring things to the point where they could bring about the benefits. ... Okay, another qualification is that a well-integrated scripting language might do everything I'm saying here, and better, because the extension/core interface is more well-defined.