From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6717 invoked by alias); 20 Apr 2007 21:55:22 -0000 Received: (qmail 6698 invoked by uid 22791); 20 Apr 2007 21:55:21 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Apr 2007 22:55:19 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 901AB4B26F; Fri, 20 Apr 2007 16:55:17 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 41B534B26D; Fri, 20 Apr 2007 16:55:17 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1Hf14T-0000Rf-Ry; Fri, 20 Apr 2007 17:55:13 -0400 Date: Fri, 20 Apr 2007 21:55:00 -0000 From: Daniel Jacobowitz To: Thiago Jung Bauermann Cc: gdb ml Subject: Re: plugin interface for GDB Message-ID: <20070420215513.GA1434@caradoc.them.org> Mail-Followup-To: Thiago Jung Bauermann , gdb ml References: <1177098228.20179.10.camel@localhost.localdomain> <20070420200004.GB28401@caradoc.them.org> <1177104071.17757.58.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1177104071.17757.58.camel@localhost.localdomain> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00130.txt.bz2 On Fri, Apr 20, 2007 at 06:21:11PM -0300, Thiago Jung Bauermann wrote: > I agree that a plugin interface and a scripting language overlap a lot > in terms of functionality. I'm not sure it would cut it in my specific > case... I'm looking at something which will potentially need to examine > 10's of GB of inferior memory in some cases and I'm a bit worried about > the performance. If there was already scripting language support in GDB, > I could do some benchmarks. It's quite possible that the overhead of the > scripting language would be low or acceptable. But right now I don't > want to work (probably a lot) on developing such support only to find > out it won't meet my performance needs... :-) Well, it's going to get developed eventually in either case. If you can't write things fast enough in Python, Python itself lets you load C modules to do the real work; the question is how fast GDB can provide memory access to the Python layer. And I think the answer is roughly as fast as GDB could get at it directly. > We want to add support in GDB to debug both IBM's JVM and programs > running on top of it at the same time. It could go into GDB proper, > except that we need to keep our modifications internal and I want to > minimize the burden of porting the code to new GDB releases, so I don't > want to mess too much with the guts of GDB. (objectionable motivation, I > know. But these are the constraints I need to work with). Not surprising constraints. The trick, for you and for us, is to minimize the amount of it is local to IBM and specific to the JVM. > As I said, a plugin interface is a good answer to that need, and I'll > probably do such interface even if only to keep it internal. > > I believe there are other people in the same situation as mine. I've > seen messages here stating something like "I'm using an old version of > GDB because I customized it and still didn't port the code to a newer > version". A plugin interface would help those people. This, you see, is the part I don't believe. I think that a _perfect_ plugin interface would help. You get to draw your own conclusions on how likely that is :-) > > I do not believe that you can come up with an abstraction layer big > > enough to be useful that is not a significant maintenance burden for > > the GDB developers. I've been surprised before, though! > > I think you'd be surprised. :-) > > I was. In a very short time we were able to come up with a working > prototype which provides very little functionality (basically, just > interaction with the user and peek inferior memory) but at the same time > is enough to meet some of our needs. > > Of course there's a long way to go from there, and code will start > getting more complex. But if it's useful enough, the maintenance burden > is bearable. The question is what you need, and how easy it is to expose in another way. I did a prototype of Guile integration in just a couple of days that did basically the same amount you've got here; and if I'd done it in Python (being a language I can actually write things in, unlike the staggering around I do in Guile), it could even have been useful. -- Daniel Jacobowitz CodeSourcery