Doug Evans <xdj...@gmail.com> skribis: > On Sun, Nov 10, 2013 at 4:19 PM, Ludovic Courtès <l...@gnu.org> wrote: >> Doug Evans <d...@sebabeach.org> skribis: >> >>> On Thu, Nov 7, 2013 at 3:39 PM, Ludovic Courtès <l...@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. > > 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, Ludo’.
