This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: guile scripting for gdb
- From: ludo at gnu dot org (Ludovic CourtÃs)
- To: Doug Evans <dje at sebabeach dot org>
- Cc: guile-user at gnu dot org, gdb-patches at sourceware dot org
- Date: Mon, 11 Nov 2013 01:19:11 +0100
- Subject: Re: guile scripting for gdb
- Authentication-results: sourceware.org; auth=none
- References: <CAA8o+=QH-gHc2GoUadfhOO4hj0=mxRbC6u0CDijAsYRvWpzvyw at mail dot gmail dot com> <87ob5vlr2s dot fsf at gnu dot org> <CAA8o+=Qhwj720CtfhUF=JuLs-GJ455uZ7gsRRripc=4vZDFWng at mail dot gmail dot com>
Doug Evans <dje@sebabeach.org> skribis:
> On Thu, Nov 7, 2013 at 3:39 PM, Ludovic CourtÃs <ludo@gnu.org> 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.
> 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.
[...]
>> 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â.