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

Stafford Horne
2017-06-10T08:17:32Z

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