From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31576 invoked by alias); 17 Feb 2007 13:51:25 -0000 Received: (qmail 31568 invoked by uid 22791); 17 Feb 2007 13:51:24 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 17 Feb 2007 13:51:18 +0000 Received: from dsl093-172-095.pit1.dsl.speakeasy.net ([66.93.172.95] helo=caradoc.them.org) by nevyn.them.org with esmtp (Exim 4.63) (envelope-from ) id 1HIPy5-0008MU-FA; Sat, 17 Feb 2007 08:51:13 -0500 Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HIPy4-0007XG-Q0; Sat, 17 Feb 2007 08:51:12 -0500 Date: Sat, 17 Feb 2007 14:07:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Jim Blandy , gdb@sourceware.org Subject: Re: GDB and scripting languages - which Message-ID: <20070217135112.GA28444@caradoc.them.org> Mail-Followup-To: Eli Zaretskii , Jim Blandy , gdb@sourceware.org References: <20070108222005.GA27451@nevyn.them.org> <20070210203307.GA27502@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) 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-02/txt/msg00185.txt.bz2 On Sat, Feb 17, 2007 at 03:15:56PM +0200, Eli Zaretskii wrote: > Is this what we intend to do in GDB? For example, are we going to > rewrite the GDB application level in the scripting language? Will we > begin accepting general-purpose GDB features that are written entirely > in the scripting language? If that's the intent, then I agree that an > extension language such as Lua is not going to be good enough. > > My impression was that we want a scripting language to do what we do > with it today: prepare canned sequences of commands for batch-style > execution, or defining customized commands that are too specialized to > be included in the upstream distribution. I thought the bulk of GDB > will remain to be in C, as it is today. Was I mistaken? I don't think we entirely know how we're going to use this yet. I have no plans to move C parts to a scripting language - I think that the scripting language should be optional, at least for one release, until we've seen how useful it is. What happens after that is harder to say. My first goal is somewhere between your two extremes. What I've always wanted is to be able to ship scripts with my application or library that explain how the debugger should display my custom data types - things like C++ STL containers, or like GDB's "struct expression", or GCC's "struct tree". Things where just displaying the underlying language type is not useful enough. There's no way to do that with our CLI scripting today. You need a language that has some other basic concepts, like strings as opposed to our current strings that live in target memory, and hierarchical data types. I imagine you could do it in either Lua or Python, once we figure out what the interface to GDB should look like. Of course, if we do this sufficiently well, it may become a vital feature for users. -- Daniel Jacobowitz CodeSourcery