This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] [0/5] Types reference counting (for VLA+Python)
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 16 Apr 2009 13:32:11 -0600
- Subject: Re: [patch] [0/5] Types reference counting (for VLA+Python)
- References: <20090411102003.GA32624@host0.dyn.jankratochvil.net>
- Reply-to: tromey at redhat dot com
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> currently GDB knows only permanent types and objfile-associated
Jan> types. GDB currently does not need more. The only special kind
Jan> are types copied from closed objfiles for value history. As the
Jan> value history is always kept in full length such types are in
Jan> fact also permanent.
FWIW, you can get a memory leak here with CVS gdb by setting a
convenience variable to a value whose type comes from an objfile,
closing all the objfiles ("file"), and then assigning a new value to
the convenience variable. In this case nothing frees the type.
Jan> To be true there exist some artificial temporary types such as in
Jan> value_cast
[...]
Jan> , these can be freed by this implemented garbage collecting
Jan> infrastructure. These are already leaking in current FSF GDB;
Jan> fix based on this framework is currently not a part of this
Jan> patchset.
Why is that? (It doesn't matter in terms of acceptance, I'm just
curious.)
Jan> This is a work based on Tom Tromey's original one but it got
Jan> changed a lot so blames to me first.
:-)
Jan> The basic decisions of this patchset are about the differences
Jan> between permant types (currently having TYPE_OBJFILE == NULL) and
Jan> garbage collectable (=reclaimable) types:
Jan> * Should the default allocation of types (alloc_type (NULL))
Jan> provide permanent type or a garbage collectable type?
Jan> = Currently it creates a permanent type.
Too bad the other approach didn't work out. Where do all these
permanent types come from? Not just init_type, I gather.
It seems strange to have a type-crawling garbage collector *and*
reference counting. But I suppose this is because enumerating the
root set is tricky.
Jan> Not tested with the Python branch (which will need to
Jan> explicitely define the allocated types as reclaimable).
I'll handle this, assuming the timing is right. We're accumulating
quite a backlog of patches to be applied after the pretty-printing
series :-(
I think your approach seems sane in general. I will comment on the
individual patches soon.
Tom