This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: beginnings of Guile support
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Doug Evans <dje at sceeck dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 06 Sep 2013 17:27:51 +0100
- Subject: Re: beginnings of Guile support
- Authentication-results: sourceware.org; auth=none
- References: <CAEei7h90tuXtBzVbNjtLQkv6ECA+EsdkYmt==MEMJcUf3m-bcA at mail dot gmail dot com>
On 06/09/13 16:35, Doug Evans wrote:
> Hi.
> As a personal project, I'm adding scheme scripting to gdb.
> This patch is very preliminary (no docs, etc. etc. etc.), but I want
> to give people a heads up.
>
> To try to plug scheme in cleanly I've created scripting.[ch] as the
> interface between gdb and python/scheme. It's not complete, not least
> of which is varobj.c, but it feels reasonable.
Nice work, Doug. In particular the architectural changes to move the
scripting language infrastructure support to a more generic naming,
and agnostic point of view. (I guess we should have thought about
this way back when).
The only comments I have are the conflicts when dealing with areas
where an internal GDB, a Python, Guile, and some other future language
conflict might occur. I noticed you removed the conditional
breakpoint check where only a Python "stop" callback can be attached
to a breakpoint, or a "traditional" GDB condition. Your work is a
work in progress, so I am not going to worry too much at the moment.
But every "stop" callback attached to a breakpoint must be allowed to
run, even if the a previous "stop" callback indicated True to stop, or
a previous condition expression attached to GDB resolved to True. I
guess we can look at this area again when your work is getting closer
to submission.
Thanks for the preview. Are you aiming for 100% feature parity with
the Python work? (IE, frame filters, etc)
Cheers,
Phil