Re: guile scripting for gdb

[Doug Evans]

On Sun, Nov 10, 2013 at 4:19 PM, Ludovic Courtès <address@hidden> wrote:
> Doug Evans <address@hidden> skribis:
>
>> On Thu, Nov 7, 2013 at 3:39 PM, Ludovic Courtès <address@hidden> wrote:
>
> [...]
>
>>> 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,
>
> What I had in mind was something simpler: suppose you have the very same
> C struct pointer reaches the Scheme level, at two different points in
> time, or via two different paths; currently gdb may end up allocating
> two different SMOBs (i.e., two SMOBs that are not eq?), whereas I would
> suggest making sure there’s only one SMOB.
>
> Example:
>
> --8<---------------cut here---------------start------------->8---
> (gdb) guile (lookup-type "int")
> #<gdb:type int>
> (gdb) guile (arch-int-type (current-arch))
> #<gdb:type int>
> (gdb) guile (eq? (lookup-type "int") (arch-int-type (current-arch)))
> #f
> --8<---------------cut here---------------end--------------->8---
>
> Here I bet the underlying ‘struct type’ pointer return by ‘lookup-type’
> is the same as that returned by ‘arch-int-type’, yet the SMOBs are
> different.
>
> Fixing it would require maintaining a C->SMOB mapping.

I'm pretty sure we have a sufficiently similar idea in mind.
I mention the use of multiple tables because the lifetimes of
different kinds of objects are different, and it may be easier to
delete the table than iterate over each element looking for entries
that need to be deleted.

For reference sake, gdb doesn't guarantee that in the above example
the underlying pointers are equal.
While the arch provides a definition of "int" it can also come from
the debug info in the program (actually there can and typically will
be several copies, one from each .o in the program).
eq-ness will be problematic even with the C->SMOB mapping.

>> 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?
>
> Yes, a lot can already be done with the current semantics, but at some
> point it may break the user’s expectations.  It’s natural to compare
> presumably-pointer-identical objects with eq?, or to use eq? hash
> tables.

No disagreement there.

> [...]
>
>>> 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.
>
> That sounds cool.  If gdb could show trace mixing both stacks, that’d be
> nice.
>
>> 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.
>
> Yeah, the VM in 2.2 is completely different.
>
> Thanks,
> Ludo’.