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

Stafford Horne shorne@gmail.com
Fri Jun 9 11:45:00 GMT 2017


On Thu, Jun 08, 2017 at 10:52:01PM +0200, Simon Marchi wrote:
> Hi Stafford,
> 
> On 2017-06-08 00:15, Stafford Horne wrote:
> > @@ -1081,17 +1080,13 @@ tdesc_remote_register_number (struct gdbarch
> > *gdbarch, int regno)
> >  }
> > 
> >  /* Check whether REGNUM is a member of REGGROUP.  Registers from the
> > -   target description may be classified as general, float, or vector.
> > -   Unlike a gdbarch register_reggroup_p method, this function will
> > -   return -1 if it does not know; the caller should handle registers
> > -   with no specified group.
> > -
> > -   Arbitrary strings (other than "general", "float", and "vector")
> > -   from the description are not used; they cause the register to be
> > -   displayed in "info all-registers" but excluded from "info
> > -   registers" et al.  The names of containing features are also not
> > -   used.  This might be extended to display registers in some more
> > -   useful groupings.
> > +   target description may be classified as general, float, vector or
> > other
> > +   register groups registerd with reggroup_add().  Unlike a gdbarch
> 
> s/registerd/registered/

Doh, I seem to never be able to spell register.

> > @@ -1231,6 +1209,27 @@ tdesc_use_registers (struct gdbarch *gdbarch,
> >  	void **slot = htab_find_slot (reg_hash, reg, INSERT);
> > 
> >  	*slot = reg;
> > +	/* Add reggroup if its new.  */
> > +	if (reg->group != NULL)
> > +	  {
> > +	    struct reggroup *group;
> > +	    bool group_exists = false;
> > +
> > +	    for (group = reggroup_next (gdbarch, NULL);
> > +		 group != NULL;
> > +		 group = reggroup_next (gdbarch, group))
> > +	      {
> > +		if (strcmp (reg->group, reggroup_name (group)) == 0)
> > +		  {
> > +		    group_exists = true;
> > +		    break;
> > +		  }
> > +	      }
> > +
> > +	    if (!group_exists)
> > +	      reggroup_add (gdbarch, reggroup_new (reg->group,
> > +						   USER_REGGROUP));
> 
> 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



More information about the Gdb-patches mailing list