From patchwork Fri Jan 26 17:25:30 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 25589 Received: (qmail 24255 invoked by alias); 26 Jan 2018 17:25:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 24245 invoked by uid 89); 26 Jan 2018 17:25:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=dtor, H*r:sk:static. X-HELO: mail-wr0-f171.google.com Received: from mail-wr0-f171.google.com (HELO mail-wr0-f171.google.com) (209.85.128.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 Jan 2018 17:25:37 +0000 Received: by mail-wr0-f171.google.com with SMTP id w50so1169973wrc.2 for ; Fri, 26 Jan 2018 09:25:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=d7GPRCTk6+wR2gwgROhSamPdt65BGDkZv5tKK0PjpAY=; b=UuXRzvCgrMh1KUqTZmyPQn87+/N9WditJyCnm9eNl+TR00X/UV8HnK1oQ4rnDPFI5J HGfhtArZNuazD8PJ6+Rd5l4ZAFn74zoAShrgTEVZRbwyMqbXtXTXufEO/PA7K727WVju D9sBoKSwPY+lkUT2dtnTT94jALOexRguASJeZWVpSn97s/fxgAM4NuyjI+1Qws/4l+EO dAPoFQHTjVNJxfh+1WVAhY8+DlKQa9ygG+xiARRdgMvGTG/JwPsVaas5aaoJ/PVHUNBr 2UaUxkvnyhqY+vETL2SFsTH6N7My4AsqjmVuTNwo2+nL8+JrUQFeRRwlzmjwMA8XwF/A jUDg== X-Gm-Message-State: AKwxyte2Lu+MBT82aOhmztLj4NxanrS789SGEefqp/VLQKPZtBATv6wR jxZxNq9yGsn/AuUzPokTNQU46w== X-Google-Smtp-Source: AH8x225yoBtECcwt+t7lvlA3z3ftjo16Wh4/FqZflg3OERWPWzCtsNIZE4KCFY1TByLF9Zln7lzJhA== X-Received: by 10.223.148.33 with SMTP id 30mr11226830wrq.190.1516987535007; Fri, 26 Jan 2018 09:25:35 -0800 (PST) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id b35sm15560559wra.13.2018.01.26.09.25.34 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 26 Jan 2018 09:25:34 -0800 (PST) From: Yao Qi To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 4/7] Class-fy partial_die_info References: <1516873114-7449-1-git-send-email-yao.qi@linaro.org> <1516873114-7449-5-git-send-email-yao.qi@linaro.org> <87vafphpw6.fsf@tromey.com> Date: Fri, 26 Jan 2018 17:25:30 +0000 In-Reply-To: <87vafphpw6.fsf@tromey.com> (Tom Tromey's message of "Thu, 25 Jan 2018 09:19:53 -0700") Message-ID: <86lggkcz1x.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Tom Tromey writes: > I wonder if it would make sense to have an "operator new" implementation > that allocates directly on an obstack. It could use Yes, we can have an "operator new", > std::is_trivially_destructible to enforce the rule that objects on an > obstack can't really be destroyed. This would eliminate the separate > XOBNEW, which is maybe a potential source of errors; and would also make > it harder to accidentally add a destructor to objects allocated this way but why dtor must be trivial? We can have "operator new" and "operator delete", the former allocate spaces on obstack and the latter doesn't de-allocate space. It doesn't matter dtor is trivial or not. I may miss something here. Further, I think IWBN to have a class which has new/delete operator, and other classes can inherit it. What do you think the patch below? diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c index 96026a8..5c45bdf 100644 --- a/gdb/dwarf2read.c +++ b/gdb/dwarf2read.c @@ -380,7 +380,7 @@ struct tu_stats /* Collection of data recorded per objfile. This hangs off of dwarf2_objfile_data_key. */ -struct dwarf2_per_objfile +struct dwarf2_per_objfile : public allocate_on_obstack { /* Construct a dwarf2_per_objfile for OBJFILE. NAMES points to the dwarf2 section names, or is NULL if the standard ELF names are @@ -2467,10 +2467,9 @@ dwarf2_has_info (struct objfile *objfile, if (dwarf2_per_objfile == NULL) { /* Initialize per-objfile state. */ - struct dwarf2_per_objfile *data - = XOBNEW (&objfile->objfile_obstack, struct dwarf2_per_objfile); - - dwarf2_per_objfile = new (data) struct dwarf2_per_objfile (objfile, names); + dwarf2_per_objfile + = new (&objfile->objfile_obstack) struct dwarf2_per_objfile (objfile, + names); set_dwarf2_per_objfile (objfile, dwarf2_per_objfile); } return (!dwarf2_per_objfile->info.is_virtual @@ -25168,10 +25167,7 @@ dwarf2_free_objfile (struct objfile *objfile) struct dwarf2_per_objfile *dwarf2_per_objfile = get_dwarf2_per_objfile (objfile); - if (dwarf2_per_objfile == NULL) - return; - - dwarf2_per_objfile->~dwarf2_per_objfile (); + delete dwarf2_per_objfile; } /* A set of CU "per_cu" pointer, DIE offset, and GDB type pointer. diff --git a/gdb/gdb_obstack.h b/gdb/gdb_obstack.h index 12a90c3..b239ce6 100644 --- a/gdb/gdb_obstack.h +++ b/gdb/gdb_obstack.h @@ -78,4 +78,18 @@ struct auto_obstack : obstack { obstack_free (this, obstack_base (this)); } }; +/* Objects are allocated on obstack instead of heap. */ + +struct allocate_on_obstack +{ + void* operator new (size_t size, struct obstack *obstack) + { + return obstack_alloc (obstack, size); + } + + void operator delete (void* memory) + { + } +}; + #endif