From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10771 invoked by alias); 8 May 2012 22:06:34 -0000 Received: (qmail 10758 invoked by uid 22791); 8 May 2012 22:06:33 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nick.hrz.tu-chemnitz.de (HELO nick.hrz.tu-chemnitz.de) (134.109.228.11) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 May 2012 22:06:18 +0000 Received: from 91-65-62-67-dynip.superkabel.de ([91.65.62.67] helo=localhost) by nick.hrz.tu-chemnitz.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SRsXx-00058z-Do; Wed, 09 May 2012 00:06:17 +0200 Date: Tue, 08 May 2012 22:06:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Abhijit Halder Cc: "gdb-patches@sourceware.org ml" Subject: Re: GDB plugin Message-ID: <20120508220615.GB3671@klara.mpi.htwm.de> References: <87vck7wxs7.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scan-AV: nick.hrz.tu-chemnitz.de;2012-05-09 00:06:17;8cc68f91e632a59146c3762c261859e4 X-Scan-SA: nick.hrz.tu-chemnitz.de;2012-05-09 00:06:17;ebaa908425f522a0beb2b6eb0d8f8152 X-Spam-Score: -1.0 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.0 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP --- Ende Textanalyse X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00243.txt.bz2 On Tue, May 08, 2012 at 11:16:11AM +0530, Abhijit Halder wrote: > [...] I am not completely aware of the limitation of this approach, > but it makes me happy thinking that the GDB users who want to extend > GDB functionality but are not well accustomed with GDB source code, > can still write their own pluggins and use an enhanced GDB without the > pain of recompilation of entire GDB source code. I guess I fit the bill of a "user[s] who want to extend GDB functionality but are not well accustomed with GDB source code" rather well. It's something I've been doing for quite a while now. However, the idea of writing plugins for GDB is not exactly appealing to me. For one. the "pain of recompilation of entire GDB source code" you mention does not exist. It's a straight-forward ./configure && make, not even with enough waiting time for a successful trip to the coffee maker (Unless you are on Windows and need to build all dependencies, but that would not be different for plugins) Secondly, GDB is pretty extensible using Python scripting already, giving "zero compile time" and platform independent access to a lot of functionality. It's hard to see how compiled plugins would improve that situation. I'd rather expect the effort for creating and maintaining a plugin interface to eat into the already scarce resources of the developers, for really not much benefit. So, please, pretty please, can we drop the idea? ;-) Andre'