[RFC 0/9] Attempt to unify Python object's lifecycle

[Jan Vrany <jan.vrany@labware.com>]

Hi,

this RFC is an attempt to systematically address Andrew's
comment on a patch I submitted earlier [1]. In particular,
this part:

> 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.

This is in fact true for other objects - gdb.Symtab, gdb.Symbol,
gdb.Type. Moreover each of these objects have their own copy
of (largely same) housekeeping code. The gdb.Block used to be
the same but not long ago it was changed so gdb.Blocks are now
interned (memoized). From the user point of view, I found it bit
counter-intuitive.

My idea was to refactor this housekeeping code into a common class.
This RFC is result of several iterations. Tested on x86_64-linux.

First four commits expand existing code to intern (memoize)
gdb.Symtab, gdb.Symbol and gdb.Type. The rest then introduces
template classes that implement necessary housekeeping and
converts gdb.Symtab, gdb.Symbol and gdb.Type to use it.
It could go further (one can convert gdb.Block too and
gdb.Value and gdb.Value.type and dynamic_type could be
further simplified too) but I decided to stop here.

The main reason is that it turned not to be as simple as
I thought - there seem to be few differences here and there
(see [2]). This complicated the housekeeping classes
(gdbpy_registry and associated "storage"). My C++ is
is pretty basic so perhaps there's better and simpler way
of doing it. Another reason is that I was hoping for some code
reduction in terms of size but looking at the result,
there's hardly any. On the other hand, the lifecycle management
is more unified across different Python objects.

All in all, I'm not sure this is the best approach and worth
it. By this RFC, I'd like to solicit feedback from experienced
GDB developers on how to move on.

Basically I see following options:

1) Do not change anything in this area (I'm perfectly
   happy with that).
2) Intern (memoize) Python objects (where it makes sense)
   but keep the current approach. Basically first four
   commits of this RFC.
3) Continue working on this.

Thanks,

Jan

[1]: https://inbox.sourceware.org/gdb-patches/87o70ar34z.fsf@redhat.com/
[2]: https://inbox.sourceware.org/gdb/6c73f834d3f7b545188e1999125e7ae63ae83eab.camel@vrany.io/T/#u

---

Jan Vrany (9):
  gdb/python: preserve identity for gdb.Symtab objects
  gdb/python: preserve identity for gdb.Symbol objects
  gdb/python: do not hold on gdb.Symtab object from gdb.Symtab_and_line
  gdb/python: preserve identity for gdb.Type objects
  gdb/python: introduce gdbpy_registry
  gdb/python: convert gdb.Symbol to use gdbpy_registry
  gdb/python: convert gdb.Type to use gdbpy_registry
  gdb/python: convert gdb.Symtab to use gdbpy_registry
  gdb/python: convert gdb.Symtab_and_line to use gdbpy_registry

 gdb/python/py-symbol.c                 |  75 +++-------
 gdb/python/py-symtab.c                 | 182 ++++++----------------
 gdb/python/py-type.c                   |  95 +++++-------
 gdb/python/python-internal.h           | 200 +++++++++++++++++++++++++
 gdb/testsuite/gdb.python/py-arch.exp   |   5 +
 gdb/testsuite/gdb.python/py-symtab.exp |  28 ++++
 gdb/testsuite/gdb.python/py-type.exp   |  15 ++
 7 files changed, 347 insertions(+), 253 deletions(-)

-- 
2.45.2