Re: [PATCH 3/3] tdesc: handle arbitrary strings in tdesc_register_in_reggroup_p

[Stafford Horne <shorne at gmail dot com>]

On Fri, Jun 09, 2017 at 09:59:08PM +0200, Simon Marchi wrote:
> On 2017-06-09 13:45, Stafford Horne wrote:
> > > Is the memory allocated by reggroup_new ever freed?
> > 
> > It is not, and its a bit tricky.  I looked through gdb, it seems the
> > reggroup objects are never freed, anywhere.  The list itself and list
> > elements (reggroup_el) are all allocated on obstack, but not reggroup.
> > 
> > It could get a bit messy to try to do something about it like refcounts
> > or
> > tracking reggroups per target description.
> > 
> > Any suggestions?
> > 
> > -Stafford
> 
> What's tricky is that some reggroup objects are owned by tdep files and are
> more or less permanent, whereas the groups provided by the tdesc are more
> transient and owned by a gdbarch instance.  A quick fix I think would be to
> have another version of reggroup_new (or the same function with additional
> parameters) that allocates the object on the gdbarch's obstack instead of
> XNEW'ing it.  The name would be obstack_strdup'ed instead of xstrdup'ed.
> This should ensure that when the gdbarch is freed, the reggroups it owns are
> freed as well.
> 
> I don't think reference counting is useful here, because there is always a
> single entity to which the lifetime of the object is tied, so it should be
> clear when to free it.
> 
> From what I can see, gdbarch's are never really freed right now, so it
> doesn't really matter right now, but I think we should do it right anyway,
> in case it ever changes.

Alright,  creating a new reggroup_new() based on obstack is what I was
thinking as well.  But I thought there might be an issue with users setting
and unsetting target descriptors.  Ill revert back it I find any trouble.

-Stafford