From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119904 invoked by alias); 9 Jan 2017 20:11: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 119885 invoked by uid 89); 9 Jan 2017 20:11:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:3BD71BF, H*MI:sk:3BD71BF, H*i:sk:3BD71BF X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jan 2017 20:11:22 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1cQgHo-0002Ly-Gh from Luis_Gustavo@mentor.com ; Mon, 09 Jan 2017 12:11:20 -0800 Received: from [172.30.7.42] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 9 Jan 2017 12:11:15 -0800 Subject: Re: [PATCH 2/3] Allocate data in cached_reg_t References: <3BD71BF1-BD32-4952-9E54-8FD14EB54987@arm.com> To: Alan Hayward , "gdb-patches@sourceware.org" CC: nd Reply-To: Luis Machado From: Luis Machado Message-ID: <29912fac-24a9-afb3-d65e-6d1796fedd14@codesourcery.com> Date: Mon, 09 Jan 2017 20:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <3BD71BF1-BD32-4952-9E54-8FD14EB54987@arm.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-02.mgc.mentorg.com (147.34.90.202) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00136.txt.bz2 On 01/09/2017 04:56 AM, Alan Hayward wrote: > Aarch64 SVE requires a max register size of 256. The current max size in gdb > is 64. This is part of a series demonstrating the replacement of > MAX_REGISTER_SIZE. > > In cached_reg_t the data is changed to a pointer, which is allocated using the > size of the register being cached. This pointer must be manually freed when > deleting a DEF_VEC of cached_reg_t's. > > Tested on x86. > Ok to commit? > > Thanks, > Alan. > > 2017-01-09 Alan Hayward > > * remote.c (struct cached_reg): Change data into a pointer. > * (stop_reply_dtr): Free data pointers before deleting vector. > (process_stop_reply): Likewise. > (remote_parse_stop_reply): Allocate space for data > > > diff --git a/gdb/remote.c b/gdb/remote.c > index 6da6eb366ae442354fd6a37741335af9a4a5a056..9247d43b094925ff397eb36b450eaba521adfc99 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -6306,7 +6306,7 @@ remote_console_output (char *msg) > typedef struct cached_reg > { > int num; > - gdb_byte data[MAX_REGISTER_SIZE]; > + gdb_byte *data; Would it make sense to go C++ and use a data structure that can take care of variable sizes? Just thinking if that would be easier than handling allocation/deallocation of the data. > } cached_reg_t; > > DEF_VEC_O(cached_reg_t); > @@ -6402,6 +6402,13 @@ static void > stop_reply_dtr (struct notif_event *event) > { > struct stop_reply *r = (struct stop_reply *) event; > + cached_reg_t *reg; > + int ix; > + > + for (ix = 0; > + VEC_iterate(cached_reg_t, r->regcache, ix, reg); > + ix++) > + xfree (reg->data); > > VEC_free (cached_reg_t, r->regcache); > } > @@ -6974,6 +6981,7 @@ Packet: '%s'\n"), > { > struct packet_reg *reg = packet_reg_from_pnum (rsa, pnum); > cached_reg_t cached_reg; > + struct gdbarch *gdbarch = target_gdbarch (); > > if (reg == NULL) > error (_("Remote sent bad register number %s: %s\n\ > @@ -6981,14 +6989,14 @@ Packet: '%s'\n"), > hex_string (pnum), p, buf); > > cached_reg.num = reg->regnum; > + cached_reg.data = (gdb_byte *) > + xmalloc (register_size (gdbarch, reg->regnum)); > > p = p1 + 1; > fieldsize = hex2bin (p, cached_reg.data, > - register_size (target_gdbarch (), > - reg->regnum)); > + register_size (gdbarch, reg->regnum)); > p += 2 * fieldsize; > - if (fieldsize < register_size (target_gdbarch (), > - reg->regnum)) > + if (fieldsize < register_size (gdbarch, reg->regnum)) > warning (_("Remote reply is too short: %s"), buf); > > VEC_safe_push (cached_reg_t, event->regcache, &cached_reg); > @@ -7211,7 +7219,11 @@ process_stop_reply (struct stop_reply *stop_reply, > for (ix = 0; > VEC_iterate(cached_reg_t, stop_reply->regcache, ix, reg); > ix++) > + { > regcache_raw_supply (regcache, reg->num, reg->data); > + xfree (reg->data); > + } > + > VEC_free (cached_reg_t, stop_reply->regcache); > } > > > >