From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82429 invoked by alias); 9 Jun 2017 11:45:48 -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 82069 invoked by uid 89); 9 Jun 2017 11:45:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 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-f179.google.com Received: from mail-pf0-f179.google.com (HELO mail-pf0-f179.google.com) (209.85.192.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 11:45:19 +0000 Received: by mail-pf0-f179.google.com with SMTP id 15so204326pfc.1 for ; Fri, 09 Jun 2017 04:45:12 -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=8zaZNEKjbO2ilU4eogq8pmWeJXZliSjK50JAjiG2sCU=; b=UC3s4z0embIhpigmG0XJMMFeflfaNAx26GWP5/Non7zKNQhk/IxeeUSkk7wcDGTWBc 6R2Q1uHVpJcqZo1N53R24+ZJb99lvnKES7CXgr6jnKNRPFpVIJaIA02k/yPnrNIsTmza xxJAV9qGIMAFVX0W3UYFznxNNnoXt/UsjKp7z4Igfchy97zukgtlE1yy9GreZJvTDbh5 x53DYW33rzURaE3+N659EFBMw70ZwsDL3aneOmUYzbCW4ghbwiYqCdWYgpHBgcuI1dnw X81uYgbFY5v2jdC9Ay+RedthM9PUQi0GKo8/538CiF0Hv69gQ0KtRWNZ1PSCvei2+lRy QDrg== X-Gm-Message-State: AODbwcCQjKSyHiioMtpEiTN6hZhDhN52BCGeiV67cglHj+SXqS6sbCk9 NB29u/tKZOhypT/ZFoY= X-Received: by 10.84.217.134 with SMTP id p6mr40284558pli.192.1497008711343; Fri, 09 Jun 2017 04:45:11 -0700 (PDT) Received: from localhost (g212.61-193-241.ppp.wakwak.ne.jp. [61.193.241.212]) by smtp.gmail.com with ESMTPSA id f1sm2340255pgc.8.2017.06.09.04.45.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 09 Jun 2017 04:45:10 -0700 (PDT) Date: Fri, 09 Jun 2017 11:45: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: <20170609114508.GB8558@lianli.shorne-pla.net> References: <0c4f5b59a645a64535e7c8bb0f34b03df805f4e4.1496871270.git.shorne@gmail.com> <59d8e3de4d7d586a39306ac65a1c7638@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59d8e3de4d7d586a39306ac65a1c7638@polymtl.ca> User-Agent: Mutt/1.8.0 (2017-02-23) X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00231.txt.bz2 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