From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100514 invoked by alias); 9 Jun 2017 19:59:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 100491 invoked by uid 89); 9 Jun 2017 19:59:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 19:59:05 +0000 Received: by simark.ca (Postfix, from userid 33) id 2E4DF1E55D; Fri, 9 Jun 2017 15:59:08 -0400 (EDT) To: Stafford Horne Subject: Re: [PATCH 3/3] tdesc: handle arbitrary strings in tdesc_register_in_reggroup_p X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 09 Jun 2017 19:59:00 -0000 From: Simon Marchi Cc: GDB patches In-Reply-To: <20170609114508.GB8558@lianli.shorne-pla.net> References: <0c4f5b59a645a64535e7c8bb0f34b03df805f4e4.1496871270.git.shorne@gmail.com> <59d8e3de4d7d586a39306ac65a1c7638@polymtl.ca> <20170609114508.GB8558@lianli.shorne-pla.net> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.5 X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00237.txt.bz2 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