From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1189 invoked by alias); 10 Jan 2017 12:59:20 -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 1130 invoked by uid 89); 10 Jan 2017 12:59:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:AES128-SHA, =e5=b0=a7, deallocate, H*f:sk:29912fa?= X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Jan 2017 12:59:17 +0000 Received: by mail-wm0-f68.google.com with SMTP id r144so20750085wme.0 for ; Tue, 10 Jan 2017 04:59:17 -0800 (PST) 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:content-transfer-encoding :in-reply-to:user-agent; bh=ZfeiIqjfj4VqzC2gz0NkHnCIdQcIygNi9TT/dlcOTpY=; b=N5qLFivJYRbinVpq4/4dS7sVBwsHj129avMPuT1RYoo+gJBXjgve1H+eXYEUIDn9b/ /F6FEl0/0UuG29yaGj+qdy4t0EXBAuWSNpwerMaWN1eb/Qr3z1FHqqLPZNq922xArvye g5upvpltiSiyTAaK4PehyJedY4dFEjfKaCEe2aiZCqyP490iCRS6CYJlgP45d1g0OigS upz54fSUaUxcp3eOfufRR79pBhBTDNdCP3fNhdmWJbHyaOXmLfpsfYC8Ebu3ccyUuTfa ZeosP71/9YK+XXGKs6OIh1M0eYLZC3h833RWbwe2YnYgTB8vUBLHzi5mywc0s5xzy/n2 98Ag== X-Gm-Message-State: AIkVDXJaBypayKnX3CFkrVqytiFMOoY4EYaYsd7PFTh58Bp374BtR9iHrl3rNI41QJuIYA== X-Received: by 10.223.164.216 with SMTP id h24mr1875637wrb.90.1484053155610; Tue, 10 Jan 2017 04:59:15 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id m10sm3140730wjg.45.2017.01.10.04.59.13 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 10 Jan 2017 04:59:15 -0800 (PST) Date: Tue, 10 Jan 2017 12:59:00 -0000 From: Yao Qi To: Luis Machado Cc: Alan Hayward , "gdb-patches@sourceware.org" , nd Subject: Re: [PATCH 2/3] Allocate data in cached_reg_t Message-ID: <20170110125905.GF9518@E107787-LIN> References: <3BD71BF1-BD32-4952-9E54-8FD14EB54987@arm.com> <29912fac-24a9-afb3-d65e-6d1796fedd14@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <29912fac-24a9-afb3-d65e-6d1796fedd14@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00155.txt.bz2 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. class cached_reg { public: cached_reg (struct gdbarch *gdbarch, int num_) : num (num_) { this->data = (gdb_byte *) xmalloc (register_size (gdbarch, num_)); } ~cached_reg () { xfree (this->data); } private: int num; gdb_byte *data; }; -- Yao (齐尧)