From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115152 invoked by alias); 17 Sep 2018 01:37:42 -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 115142 invoked by uid 89); 17 Sep 2018 01:37:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=reserved X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Sep 2018 01:37:40 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1E4A11E021; Sun, 16 Sep 2018 21:37:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=simark.ca; s=mail; t=1537148258; bh=a/vvRbMi+FpSUjiNvtPG1Fj9mPdopEoBORIeQw0oIj0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=tOyIM1gEtvoj1dYYly5nOPbL/u9m2lb3uifF9zZFXKmc9VEomgpmMhoqQh1B01s4D qYfz8+ZpA4iNF1X0WOe5Xo7xHclJZRp0nnm6M92JtO06rQjAA299m2BTa22IcF3Slh 2p0isjrAZCIdRDyIGwfWIcFOK29zfWLlo+69fNDQ= Subject: Re: [PATCH 1/2] Remove munmap_listp_free_cleanup To: Tom Tromey , gdb-patches@sourceware.org References: <20180915222411.24764-1-tom@tromey.com> <20180915222411.24764-2-tom@tromey.com> From: Simon Marchi Message-ID: <04207066-48a5-b93e-540e-b6bfefb3f07b@simark.ca> Date: Mon, 17 Sep 2018 01:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180915222411.24764-2-tom@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00555.txt.bz2 On 2018-09-15 6:24 p.m., Tom Tromey wrote: > diff --git a/gdb/compile/compile-object-load.h b/gdb/compile/compile-object-load.h > index 6f62535878a..7569c42bf5c 100644 > --- a/gdb/compile/compile-object-load.h > +++ b/gdb/compile/compile-object-load.h > @@ -18,8 +18,31 @@ > #define GDB_COMPILE_OBJECT_LOAD_H > > #include "compile-internal.h" > +#include > > -struct munmap_list; > +struct munmap_list > +{ > +public: > + > + munmap_list () = default; > + ~munmap_list (); > + > + DISABLE_COPY_AND_ASSIGN (munmap_list); > + > + /* Add a region to the list. */ > + void add (CORE_ADDR addr, CORE_ADDR size); > + > +private: > + > + /* Track inferior memory reserved by inferior mmap. */ > + > + struct munmap_item > + { > + CORE_ADDR addr, size; > + }; > + > + std::list items; Not a big deal, but we might as well use a vector. The objects are cheap to copy, so there's probably less overhead overall (memory and time) to use a vector than a doubly linked list. I was going to say: 1. Why not use munmap_list as directly as field of setup_sections_data, instead of a unique_ptr, and 2. std::move it to the compile_module object. But that would require C++ifying compile_module and probably do_module_cleanup too, and that's perhaps a too big of a step for this patch. Simon