Re: guile scripting for gdb

[Doug Evans <dje at sebabeach dot org>]

On Thu, Nov 7, 2013 at 3:39 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hello,
>
> Doug Evans <dje@sebabeach.org> skribis:
>
>> fyi, I've uploaded my gdb-guile branch to github.
>>
>> https://github.com/dje42/gdb.git
>>
>> It's in branch gdb-guile.
>
> Nice piece of work from several angles (implementation strategy, test
> coverage, style, docstrings, comments, etc.)

To be fair, a lot of it derives from the Python version (gdb/python/*.[ch]).

>> It's still very preliminary, there's still lots to do, and there are
>> some open issues.
>
> As discussed on IRC, one possible issue is eq?-ness of SMOBs: one would
> usually expects pointer equality to be preserved at the Scheme level.

Yeah.
That'll require gdb maintaining its own table(s) for each kind of smob
we want to intern.
Definitely doable, though there are some issues.
E.g., while std::vector<int> may be the same type in two different programs,
if we want eq?-ness to survive across the lifetime of the underlying gdb object
then that would take extra effort to make that work.
Would it be ok to punt on eq?-ness until there's a compelling reason
to make it work?
At that point we'd have a better idea of the use-case involved, and data on
the speed improvement eq? would bring to the table in that instance.
And even then we might still have eq?-ness defined by the lifetime of the
underlying gdb object (until there's a compelling reason to then make
that work).

> Another question I had is the lifetime of Scheme objects vs. that of the
> underlying C objects.  AIUI C objects cannot be forcefully kept alive
> when their Scheme representative is live, which is why the bindings have
> this notion of “invalid” object at the Scheme level.  Is it also the way
> the Python bindings deal with the issue?
>
> Random remarks:
>
>   • The disasm interface looks cool.  I think it’d be more convenient if
>     it used records to represent disassembled instructions.

Thanks.  I wanted to make it general so that we could disassemble more
than just code from the program.

I wasn't sure which things to make as records or goops objects or ...
So I'm starting small.
Each disassembly is just immutable data so it's easy enough
to write wrappers to provide the API one wants.

>   • It would be nice to wrap the iterator interface in SRFI-41 streams.

Yeah, I have a TODO to look into that.

> An interesting exercise would be to write pretty-printers for SCM values
> and tools to walk Guile’s VM stack (like Guile’s gdbinit attempts to do).

Agreed, excellent exercises.

gdb has a "frame filter" interface that's intended to be used to
implement multi-language backtraces.
Need to add a gdb/guile interface.
I'm not sure how Guile's new VM changes things - someone may want to
write one for 2.0 and one for 2.2.