From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23236 invoked by alias); 20 Apr 2007 19:44:09 -0000 Received: (qmail 23226 invoked by uid 22791); 20 Apr 2007 19:44:08 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Apr 2007 20:44:06 +0100 Received: from mailhub3.br.ibm.com (unknown [9.18.232.110]) by igw3.br.ibm.com (Postfix) with ESMTP id BC6FD3902A1 for ; Fri, 20 Apr 2007 16:36:44 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3KJhmfM1773670 for ; Fri, 20 Apr 2007 16:43:48 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3KJggqA018191 for ; Fri, 20 Apr 2007 16:42:42 -0300 Received: from dyn532128.br.ibm.com (dyn532128.br.ibm.com [9.18.238.251]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3KJggiZ018188 for ; Fri, 20 Apr 2007 16:42:42 -0300 Subject: plugin interface for GDB From: Thiago Jung Bauermann To: gdb ml Content-Type: text/plain Date: Fri, 20 Apr 2007 19:44:00 -0000 Message-Id: <1177098228.20179.10.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/msg00124.txt.bz2 Hi folks, I am interested in developing a plugin interface for GDB, and would like to know what are your thoughts about it. Would you find such feature useful? Would it be integrated into GDB? This is useful to me, so I'll probably do it even if there's no plan to integrate the plugin interface upstream (in fact, I have a very basic working prototype already). But if there is community interest in such thing, I'd like to do it in a way that will increase its chance of integration and shape it so that more people could benefit from it. I saw some discussion on this subject in the following thread: http://sourceware.org/ml/gdb/2002-04/msg00371.html But it didn't come to a conclusion, so I'd like to revisit the idea. Motivation for having a plugin interface: - enable seamless debugging of programs written in multiple languages (Java + C, Python + C, etc) (in fact, this is the reason I need the plugin interface.) - useful for specialized debugging (specific problem domain) - lessens the need to maintain custom GDBs. You just use a standard GDB and write a plugin (or use an existing one). If you decide to upgrade GDB, you won't need to port your code and not even recompile the plugin (ideally, if we manage to design a resilient interface). - allow people outside of the core GDB team to implement distribute and test their plugins without modifying GDB. - lowers the bar to creating modifications to GDB (exposes a well defined interface, so there's no need to learn the ins and outs of GDB to write the plugin you need/want) 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. Each approach has advantages and disadvantages, but some of the advantages I pointed out above only hold if you have such abstraction layer. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center