Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Stafford Horne <shorne@gmail.com>
Cc: GDB patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 3/3] tdesc: handle arbitrary strings in  tdesc_register_in_reggroup_p
Date: Fri, 09 Jun 2017 19:59:00 -0000	[thread overview]
Message-ID: <f85e388c9b9823e9871fac02e1b3da14@polymtl.ca> (raw)
In-Reply-To: <20170609114508.GB8558@lianli.shorne-pla.net>

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.

Simon


  reply	other threads:[~2017-06-09 19:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-07 22:15 [PATCH 0/3] Support for arbitrary reggroups Stafford Horne
2017-06-07 22:16 ` [PATCH 1/3] reggroups: Add test and docs for `info reg $reggroup` feature Stafford Horne
2017-06-08  2:38   ` Eli Zaretskii
2017-06-08  4:59     ` Stafford Horne
2017-06-08 20:31   ` Simon Marchi
2017-06-08 23:27     ` Stafford Horne
2017-06-09  6:20       ` Simon Marchi
2017-06-13 11:17   ` Pedro Alves
2017-06-07 22:16 ` [PATCH 3/3] tdesc: handle arbitrary strings in tdesc_register_in_reggroup_p Stafford Horne
2017-06-08  2:40   ` Eli Zaretskii
2017-06-08  5:01     ` Stafford Horne
2017-06-08 14:56       ` Eli Zaretskii
2017-06-08 20:52   ` Simon Marchi
2017-06-09 11:45     ` Stafford Horne
2017-06-09 19:59       ` Simon Marchi [this message]
2017-06-10  8:17         ` Stafford Horne
2017-06-13 11:17   ` Pedro Alves
2017-06-07 22:16 ` [PATCH 2/3] reggroups: Convert reggroups from post_init to pre_init Stafford Horne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f85e388c9b9823e9871fac02e1b3da14@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=shorne@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox