From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12927 invoked by alias); 7 Nov 2002 21:10:47 -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 12919 invoked from network); 7 Nov 2002 21:10:46 -0000 Received: from unknown (HELO dc-mx04.cluster1.charter.net) (209.225.8.14) by sources.redhat.com with SMTP; 7 Nov 2002 21:10:46 -0000 Received: from [66.189.46.2] (HELO platinum.localnet) by dc-mx04.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with ESMTP id 23754261; Thu, 07 Nov 2002 16:10:45 -0500 Date: Thu, 07 Nov 2002 13:10:00 -0000 Subject: Re: [PATCH] plugin patch Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Andrew Cagney , Scott Moser , Jelmer Vernooij , Eli Zaretskii , gdb-patches@sources.redhat.com To: "Paul A. Clarke" From: Klee Dienes In-Reply-To: <1036692161.539.213.camel@pclarke> Message-Id: <6019DB4E-F295-11D6-BABF-00039396EEB8@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00200.txt.bz2 We've also been using our own version of GDB plug-ins at Apple, and have found them to be rather handy at times. Three examples of places where plug-ins have been used: * While doing performance analysis, I wrote a 100-line plug-in that hooks up GDB to a Mac OS X-specific performance monitoring library. The change is OSX-specific and uses Objective-C, and there's just about zero chance it would ever be appropriate for the main-line GDB sources, nor do I want it cluttering up our local branch when I'm not using it. But as a plug-in, I can just load it into my GDB when I need it for performance analysis. * Our kernel developers sometimes find themselves dumping insanely nasty structures that can take quite a while to print using the core GDB. GDB plug-ins let them write custom viewers/dumpers (typically 10x or more faster) without going through the hassle of maintaining a GDB tree or keeping custom binaries around. * One of my crazy co-workers wrote a complete MacsBug front-end to GDB as a plug-in as a "nights and weekends" project. This isn't something that we want to support in our core GDB sources, nor is it something I'd really expect the FSF folks to be particularly interested in picking up. But it was a really cool hack, and one that was developed completely independently of our core GDB work. On Thursday, November 7, 2002, at 01:02 PM, Paul A. Clarke wrote: > > - Scott started working on a GDB plug-in for libgtk, which would allow > a > developer to 'somehow' highlight certain widgets on demand, given a > widget's handle > - a similar GDB plug-in for libGL, which can track the OpenGL state > machine and validate calls as they are made > - a GDB plug-in which can trace calls to a given API, with knowlege > about parameter types and ranges > - a potentially large plug-in for GDB which can make use of > processor-specific performance monitoring capabilities > - a potentially large plug-in for GDB which does really goofy things to > the inferior like code surgery or error correction on-the-fly > > (No, I don't have examples of these. Yet! I wish I did.) It didn't > take too much brainstorming to come up with what (I hope) are decent > examples where plug-in/module support would be useful (you wouldn't > want > to integrate all of those into GDB, would you?) and would accelerate > the > advancement of GDB into new and broader areas, and all code would > necessarily be GPL'd. > > Regards (and thanks for your patience and attention!), > Paul Clarke >