From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27595 invoked by alias); 9 Jan 2007 20:11:29 -0000 Received: (qmail 27510 invoked by uid 22791); 9 Jan 2007 20:11:23 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Jan 2007 20:11:12 +0000 Received: (qmail 10131 invoked from network); 9 Jan 2007 20:11:11 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Jan 2007 20:11:11 -0000 To: gdb@sourceware.org Subject: Re: GDB and scripting languages - which References: <20070108222005.GA27451@nevyn.them.org> From: Jim Blandy Date: Tue, 09 Jan 2007 20:11:00 -0000 In-Reply-To: <20070108222005.GA27451@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 8 Jan 2007 17:20:05 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-01/txt/msg00150.txt.bz2 I would prefer that GDB use a single extension language, and that that language be Python. Python has more momentum than Guile in almost any way one might measure it: - number of users who are familiar with it - body of large programs written in it - number of modules available for reuse - number of programs embedding it - number of books available for learning it (I was the maintainer of Guile for several years, and I say this with much kind regard for the people who have invested their time and talents in Guile. But Guile has had more than enough time to attract uses and users on its own merits, and compared to Python, it hasn't worked out. It's time to cut our losses.) It takes a lot of effort to pull together a useful interface for an application. Sustaining that effort for several different extension languages would be a substantial burden. I understand that it's a quick weekend's work to implement a Guile or Python function that passes MI requests and responses back and forth between Guile and GDB. But this is just a bare stub of an interface. An extension language interface needs to provide higher-level functions: - create and delete breakpoints, with callbacks when hit - look up symbols - enumerate object files, compilation units, functions, local variables - pattern-match and construct types - map between source locations and machine code locations - represent container types like C++ map<> and vector<> in terms of their interface, not their implementation: a map<> is a key/value mapping, not a red-black tree; a vector<> is an ordered series of elements, not a length, size, and content pointer, or however it's done All these things can be done via MI (perhaps with some extensions), but it would be silly to have everyone writing their own functions to send MI back and forth; there should be a library of functions to do all this for you, so script authors can concentrate on what they actually want GDB to do, instead of managing the details of MI. Maintaining such libraries for multiple extension languages would be wasted work, and python is good enough.