From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96347 invoked by alias); 10 Jan 2017 17:42:31 -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 96324 invoked by uid 89); 10 Jan 2017 17:42:30 -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=deallocate, H*f:sk:29912fa 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; Tue, 10 Jan 2017 17:42:29 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1cR0RI-0006lF-3w from Luis_Gustavo@mentor.com ; Tue, 10 Jan 2017 09:42:28 -0800 Received: from [172.30.6.249] (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; Tue, 10 Jan 2017 09:42:24 -0800 Reply-To: Luis Machado Subject: Re: [PATCH 2/3] Allocate data in cached_reg_t References: <3BD71BF1-BD32-4952-9E54-8FD14EB54987@arm.com> <29912fac-24a9-afb3-d65e-6d1796fedd14@codesourcery.com> <20170110125905.GF9518@E107787-LIN> To: Yao Qi CC: Alan Hayward , "gdb-patches@sourceware.org" , nd From: Luis Machado Message-ID: <4553e987-6404-8123-eae7-48f85bf62388@codesourcery.com> Date: Tue, 10 Jan 2017 17:42: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: <20170110125905.GF9518@E107787-LIN> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-01.mgc.mentorg.com (147.34.90.201) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00173.txt.bz2 On 01/10/2017 06:59 AM, Yao Qi wrote: > On 17-01-09 14:11:13, Luis Machado wrote: >>> @@ -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. >> > > Do you suggest std::vector? We still need to allocate/deallocate it > if we change "gdb_byte *data" to "std::vector *data", or we > have to convert cached_reg to class, and do RAII. > Something like std::vector, yes. But it is true we will still need to allocate the vector itself. I was pondering about the benefits of not being limited to a specific register size. Then we wouldn't need to worry about adjusting things as we have to do now. As i see it, data[register_size(register_size (gdbarch, num)] wouldn't be much different than data[MAX_REGISTER_SIZE]. The only thing is that we're setting the max register size dynamically. We may or may not need this flexibility right now, but who knows what weird architectures we may have in the future.