From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28946 invoked by alias); 20 Apr 2007 21:39:16 -0000 Received: (qmail 28938 invoked by uid 22791); 20 Apr 2007 21:39:15 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Apr 2007 22:39:13 +0100 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 3210F5BDF0 for ; Fri, 20 Apr 2007 18:32:21 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3KLdAMM1417320 for ; Fri, 20 Apr 2007 18:39:10 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3KLb9P5011364 for ; Fri, 20 Apr 2007 18:37:09 -0300 Received: from dyn532128.br.ibm.com (dyn532128.br.ibm.com [9.18.238.251]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3KLb9hl011361 for ; Fri, 20 Apr 2007 18:37:09 -0300 Subject: Re: plugin interface for GDB From: Thiago Jung Bauermann To: gdb@sourceware.org In-Reply-To: <46291B10.F439FB8B@dessent.net> References: <1177098228.20179.10.camel@localhost.localdomain> <46291B10.F439FB8B@dessent.net> Content-Type: text/plain Date: Fri, 20 Apr 2007 21:39:00 -0000 Message-Id: <1177105150.17757.74.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit 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/msg00129.txt.bz2 On Fri, 2007-04-20 at 12:57 -0700, Brian Dessent wrote: > > Scott Moser's idea was to have very basic plugin support (loading and > > unloading), and leave to the plugin writer the work of searching which > > internal GDB functions he'd need to use and directly call them from the > > plugin code. I am more inclined to go into a different direction, which > > is to provide an abstraction layer which would expose functionality > > which is potentially useful for a plugin. > > You should read the recent threads about adding scripting support to > gdb. The one from several months ago > seemed to > mostly converge on Python, with tcl and guile as runners up. > > To me it seems like it would be a lot easier to go in that direction > than to actually allow for plugins in the sense of dynamically loading a > shared module of compiled code. I saw that thread. It's certainly very desirable functionality. My problem is that maybe it would meet my needs, maybe not. Like I just mentioned in a message to Daniel, we'll be looking at lots of data. I'm not sure what would be the performance of that... Also, we have a lot of C code which we'll integrate with GDB, so a layer of interpreted language is unnecessary to us and just adds complexity. > In either case, you have to implement > some kind of API that exposes the internals of gdb to the plugin or the > script, and in either case you can extend the functionality of gdb in > pretty much arbitrary ways. Agreed. Both features overlap a lot in terms of functionality provided to users, but I'm afraid they are not completely equivalent. I think this discussion is a good opportunity to try to determine this. > But in the case of scripting you don't have > ABI headaches to worry about, You mean keeping binary compatibility with plugins accross different GDB versions? That's a nice goal, but not worth worrying about too much, I think. > and it increases accessilbility since you > can express relatively high level concepts easily in just a short amount > of python script, compared to having to code the same amount of > functionality with a C plugin. Agreed. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center