[RFC v2 10/21] gdb/python: add gdb.Compunit

[Jan Vraný]

Hi, 

On Mon, 2025-01-13 at 18:15 +0000, Andrew Burgess wrote:
> Jan Vrany <jan.vrany@labware.com> writes:
> 
> 
> 
> > +
> > +  return gdbpy_ref<>::new_reference ((PyObject * )compunit_obj);
> > +}
> 
> I don't really like the approach taken by this function.  Each time
> the
> function is called we get a new gdb.Compunit object created and
> chained
> onto the objfile.
> 
> Now, I know that the use of gdbpy_richcompare means that the
> different
> objects will compare as equal.  But I think it would be better to
> just
> reuse the existing objects, i.e. have this function search the chain
> of
> objects looking for a match.

I'm with you - I'm not a big fan of this approach either. But: this is
exactly how other objfile-owned Python objects are implemented,
gdb.Symtab, gdb.Symbol. It was also the case for gdb.Type until Tom
changed it not long ago. And this is why I needed gdbpy_richcompare.

In fact, in an early iteration of this code I did something along the
lines of what you suggested but then decided not to do that and 
just fall in line with the others.

I can try revive that code and convert (at least) gdb.Symtab and
gdb.Symbol in a separate series (this one feels little-too-
big already) and once done, get back to this series. This would 
also make it easier to add new objects in the future (gdb.Section
and gdb.MinimalSymbol come to mind).

> 
> Additionally, and I didn't know if this was intentional or not,
> PyObject_NEW returns a new reference, i.e. the object returned has a
> refcount of 1 already.  So why you return the
> gdbpy_ref<>::new_reference(), the object you return has a refcount of
> 2.
> 
> What this means is that cupy_dealloc is never called as each
> compunit_object chained off the objfile has a base refcount of 1, and
> when cupy_deleter::operator() is called, I think we end up leaking
> the
> Python objects.

Yeah, this is a bug. Thanks! 

Thanks! 

Jan