From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24157 invoked by alias); 7 Nov 2002 18:05:06 -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 24087 invoked from network); 7 Nov 2002 18:05:05 -0000 Received: from unknown (HELO e3.ny.us.ibm.com) (32.97.182.103) by sources.redhat.com with SMTP; 7 Nov 2002 18:05:05 -0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA7I4l4Z006622; Thu, 7 Nov 2002 13:04:47 -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 gA7I4jmn170660; Thu, 7 Nov 2002 13:04:45 -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: <3DC9AC44.2090209@redhat.com> References: <20021106145415.GA2350@charis.vernstok> <20021106155151.GA2522@charis.vernstok> <3DC94DD8.10009@redhat.com> <1036623919.539.145.camel@pclarke> <3DC9AC44.2090209@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 07 Nov 2002 10:05:00 -0000 Message-Id: <1036692161.539.213.camel@pclarke> Mime-Version: 1.0 X-SW-Source: 2002-11/txt/msg00181.txt.bz2 On Wed, 2002-11-06 at 17:56, Andrew Cagney wrote: > > 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. > > Cool! Can you contribute it to the FSF so that it can be integrated > into GDB? I'd love to! The only issues, aside from paperwork, are: - it's based on Scott's plug-in enablement patch - it currently only works on x86 (tested on GNU/Linux) This last point leads into my next pitch for plug-in support (you had to expect it, right? ;-) Would you consider the following as valid reasons for supporting optional functionality via a dynamically-loaded plug-in/module mechanism? - generally useful function which isn't yet ported to multiple architectures - useful function, but only to a niche audience - useful function, but of significant size, large enough to warrant only building and/or loading it when desired For example, as I mentioned previously, function which has apriori knowledge of specific libraries/APIs, or function which is very architecture-specific. Specific examples are numerous, and include: - 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