Re: GDB and scripting languages - which

[Daniel Jacobowitz <drow@false.org>]

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