This is the mail archive of the
mailing list for the GDB project.
Re: guile scripting for gdb
- From: ludo at gnu dot org (Ludovic CourtÃs)
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: Doug Evans <dje at sebabeach dot org>, guile-user at gnu dot org, gdb-patches at sourceware dot org
- Date: Mon, 11 Nov 2013 12:47:51 +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> <87k3gfpz7k dot fsf at gnu dot org> <CAP9bCMQVz1X_DnNQYQzEY4RnY6wCbUbjeO-T0MDtu=xO0FFBpQ at mail dot gmail dot com>
Doug Evans <email@example.com> skribis:
> On Sun, Nov 10, 2013 at 4:19 PM, Ludovic CourtÃs <firstname.lastname@example.org> wrote:
>> Doug Evans <email@example.com> skribis:
>>> On Thu, Nov 7, 2013 at 3:39 PM, Ludovic CourtÃs <firstname.lastname@example.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.
>>> 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.
>> --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)))
>> --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
>> 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.
Ah, OK. Indeed, eq?-ness only would only matter in cases where gdb
guarantees pointer equality in the first place.
Thanks for the explanation,