From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78834 invoked by alias); 10 Jun 2017 08:17:32 -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 78819 invoked by uid 89); 10 Jun 2017 08:17:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-pf0-f195.google.com Received: from mail-pf0-f195.google.com (HELO mail-pf0-f195.google.com) (209.85.192.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 10 Jun 2017 08:17:30 +0000 Received: by mail-pf0-f195.google.com with SMTP id w12so913568pfk.0 for ; Sat, 10 Jun 2017 01:17:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=M8dd6x9JIKN9MdsBE7Dl5ZIAgBfPNt694UV67no9KEc=; b=boCg0w/VGJgrhKLwpCb/Au9hWO+QgItrEZkyS/lHzogb2VR9PVvStdf4E82YNIwnoO 6wvE2l7vwSgriiaMmcMIOZ7BovLE40SckHZhf+OZRhr9i5eJI7KC0TxyvxkUWSlpsbAl 2JrzWb1JDjGoEibG8uRwuUDkdD8vZEsVm3N8sUw6gfT6+v7fjRWWS0AWUy/ABLT/SKCm 8cL427KVsoQf6ZmpmtqI0+b8Lq3OfbLsch9T7CYNkuE9By+Oeaj12j7v45aDpLfSEAZk gOZNW8UH9ntWSPLnc7eMvJw6cLSZIo+KyUf2Cn/85AtRFCThFvnY19biaIcvzvVa4deE fceQ== X-Gm-Message-State: AODbwcBdBmBFUBuLPdvhV9TgWTyMqHTO9RXHCB7cl6yQGwc/bZ94x7kq rT1Yf3JonMxkiQ== X-Received: by 10.84.229.143 with SMTP id c15mr46015717plk.27.1497082653400; Sat, 10 Jun 2017 01:17:33 -0700 (PDT) Received: from localhost (g212.61-193-241.ppp.wakwak.ne.jp. [61.193.241.212]) by smtp.gmail.com with ESMTPSA id w67sm6660223pfi.2.2017.06.10.01.17.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 10 Jun 2017 01:17:32 -0700 (PDT) Date: Sat, 10 Jun 2017 08:17:00 -0000 From: Stafford Horne To: Simon Marchi Cc: GDB patches Subject: Re: [PATCH 3/3] tdesc: handle arbitrary strings in tdesc_register_in_reggroup_p Message-ID: <20170610081730.GB6190@lianli.shorne-pla.net> References: <0c4f5b59a645a64535e7c8bb0f34b03df805f4e4.1496871270.git.shorne@gmail.com> <59d8e3de4d7d586a39306ac65a1c7638@polymtl.ca> <20170609114508.GB8558@lianli.shorne-pla.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00242.txt.bz2 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