Patchwork New class allocate_on_obstack

login
register
mail settings
Submitter Yao Qi
Date Feb. 7, 2018, 9:40 a.m.
Message ID <1517996444-8605-1-git-send-email-yao.qi@linaro.org>
Download mbox | patch
Permalink /patch/25842/
State New
Headers show

Comments

Yao Qi - Feb. 7, 2018, 9:40 a.m.
This patch adds a new class allocate_on_obstack, and let dwarf2_per_objfile
inherit it, so that dwarf2_per_objfile is automatically allocated on
obstack, and "delete dwarf2_per_objfile" doesn't de-allocate any space.

Regression tested on x86_64-linux.

gdb:

2018-02-06  Yao Qi  <yao.qi@linaro.org>

	* block.c (block_namespace_info): Inherit allocate_on_obstack.
	(block_initialize_namespace): Use new.
	* dwarf2read.c (dwarf2_per_objfile): Inherit allocate_on_obstack.
	(dwarf2_free_objfile): Use delete.
	* gdbtypes.c (type_pair): Inherit allocate_on_obstack.
	(copy_type_recursive): Use new.
	* gdb_obstack.h (allocate_on_obstack): New.
---
 gdb/block.c       | 12 ++++--------
 gdb/dwarf2read.c  | 14 +++++---------
 gdb/gdb_obstack.h | 20 ++++++++++++++++++++
 gdb/gdbtypes.c    | 18 +++++++++++-------
 4 files changed, 40 insertions(+), 24 deletions(-)
Pedro Alves - Feb. 7, 2018, 3:20 p.m.
On 02/07/2018 09:40 AM, Yao Qi wrote:
> This patch adds a new class allocate_on_obstack, and let dwarf2_per_objfile
> inherit it, so that dwarf2_per_objfile is automatically allocated on
> obstack, and "delete dwarf2_per_objfile" doesn't de-allocate any space.
> 
> Regression tested on x86_64-linux.

LGTM.

Thanks,
Pedro Alves
Tom Tromey - Feb. 7, 2018, 3:29 p.m.
>>>>> "Yao" == Yao Qi <qiyaoltc@gmail.com> writes:

Yao> This patch adds a new class allocate_on_obstack, and let dwarf2_per_objfile
Yao> inherit it, so that dwarf2_per_objfile is automatically allocated on
Yao> obstack, and "delete dwarf2_per_objfile" doesn't de-allocate any space.

I still think it should be restricted to types with a trivial
destructor.  Otherwise, someday, the lack of actual destruction is going
to cause a bug.

Tom
Yao Qi - Feb. 7, 2018, 5:34 p.m.
On Wed, Feb 7, 2018 at 3:29 PM, Tom Tromey <tom@tromey.com> wrote:
>>>>>> "Yao" == Yao Qi <qiyaoltc@gmail.com> writes:
>
> Yao> This patch adds a new class allocate_on_obstack, and let dwarf2_per_objfile
> Yao> inherit it, so that dwarf2_per_objfile is automatically allocated on
> Yao> obstack, and "delete dwarf2_per_objfile" doesn't de-allocate any space.
>
> I still think it should be restricted to types with a trivial
> destructor.  Otherwise, someday, the lack of actual destruction is going
> to cause a bug.
>

Can you give me some clues on how to do the restriction?  I think I need to
use std::enable_if and std::is_trivially_destructible, but don't know how to put
them into the code.

Lack of destruction causes a bug in any case.  If object is allocated on heap,
and don't do "delete p", the dtor isn't called and memory is leaked.  I
expect use "delete p" no matter where the object is allocated (on heap or
on obstack).
Yao Qi - Feb. 8, 2018, 8:58 p.m.
On Wed, Feb 7, 2018 at 5:34 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
> On Wed, Feb 7, 2018 at 3:29 PM, Tom Tromey <tom@tromey.com> wrote:
>>>>>>> "Yao" == Yao Qi <qiyaoltc@gmail.com> writes:
>>
>> Yao> This patch adds a new class allocate_on_obstack, and let dwarf2_per_objfile
>> Yao> inherit it, so that dwarf2_per_objfile is automatically allocated on
>> Yao> obstack, and "delete dwarf2_per_objfile" doesn't de-allocate any space.
>>
>> I still think it should be restricted to types with a trivial
>> destructor.  Otherwise, someday, the lack of actual destruction is going
>> to cause a bug.
>>
>
> Can you give me some clues on how to do the restriction?  I think I need to
> use std::enable_if and std::is_trivially_destructible, but don't know how to put
> them into the code.
>

I somehow managed to write static_assert std::is_trivially_destructible<T>
for these classes, and dwarf2_per_objfile is not trivially destructible.
Classes inherit allocate_on_obstack don't have to be is_trivially_destructible,
IMO.

> Lack of destruction causes a bug in any case.  If object is allocated on heap,
> and don't do "delete p", the dtor isn't called and memory is leaked.  I
> expect use "delete p" no matter where the object is allocated (on heap or
> on obstack).

We can still let dwarf2_per_objfile inherit allocate_on_obstack or allocate
dwarf2_per_objfile on obstack, but is still better to use "delete" to call dtor.
Yao Qi - Feb. 16, 2018, 4:22 p.m.
Yao Qi <qiyaoltc@gmail.com> writes:

> 2018-02-06  Yao Qi  <yao.qi@linaro.org>
>
> 	* block.c (block_namespace_info): Inherit allocate_on_obstack.
> 	(block_initialize_namespace): Use new.
> 	* dwarf2read.c (dwarf2_per_objfile): Inherit allocate_on_obstack.
> 	(dwarf2_free_objfile): Use delete.
> 	* gdbtypes.c (type_pair): Inherit allocate_on_obstack.
> 	(copy_type_recursive): Use new.
> 	* gdb_obstack.h (allocate_on_obstack): New.

I pushed it in.

Patch

diff --git a/gdb/block.c b/gdb/block.c
index 57da7ba..f26d169 100644
--- a/gdb/block.c
+++ b/gdb/block.c
@@ -31,10 +31,10 @@ 
    C++ files, namely using declarations and the current namespace in
    scope.  */
 
-struct block_namespace_info
+struct block_namespace_info : public allocate_on_obstack
 {
-  const char *scope;
-  struct using_direct *using_decl;
+  const char *scope = nullptr;
+  struct using_direct *using_decl = nullptr;
 };
 
 static void block_initialize_namespace (struct block *block,
@@ -350,11 +350,7 @@  static void
 block_initialize_namespace (struct block *block, struct obstack *obstack)
 {
   if (BLOCK_NAMESPACE (block) == NULL)
-    {
-      BLOCK_NAMESPACE (block) = XOBNEW (obstack, struct block_namespace_info);
-      BLOCK_NAMESPACE (block)->scope = NULL;
-      BLOCK_NAMESPACE (block)->using_decl = NULL;
-    }
+    BLOCK_NAMESPACE (block) = new (obstack) struct block_namespace_info ();
 }
 
 /* Return the static block associated to BLOCK.  Return NULL if block
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index d651725..c38eb4e 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
@@ -2490,10 +2490,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
@@ -25191,10 +25190,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..f91e61a 100644
--- a/gdb/gdb_obstack.h
+++ b/gdb/gdb_obstack.h
@@ -78,4 +78,24 @@  struct auto_obstack : obstack
   { obstack_free (this, obstack_base (this)); }
 };
 
+/* Objects are allocated on obstack instead of heap.  */
+
+struct allocate_on_obstack
+{
+  allocate_on_obstack () = default;
+
+  void* operator new (size_t size, struct obstack *obstack)
+  {
+    return obstack_alloc (obstack, size);
+  }
+
+  void* operator new[] (size_t size, struct obstack *obstack)
+  {
+    return obstack_alloc (obstack, size);
+  }
+
+  void operator delete (void* memory) {}
+  void operator delete[] (void* memory) {}
+};
+
 #endif
diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index 79bb659..b3a0379 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -4699,9 +4699,13 @@  recursive_dump_type (struct type *type, int spaces)
 /* Trivial helpers for the libiberty hash table, for mapping one
    type to another.  */
 
-struct type_pair
+struct type_pair : public allocate_on_obstack
 {
-  struct type *old, *newobj;
+  type_pair (struct type *old_, struct type *newobj_)
+    : old (old_), newobj (newobj_)
+  {}
+
+  struct type * const old, * const newobj;
 };
 
 static hashval_t
@@ -4769,7 +4773,6 @@  copy_type_recursive (struct objfile *objfile,
 		     struct type *type,
 		     htab_t copied_types)
 {
-  struct type_pair *stored, pair;
   void **slot;
   struct type *new_type;
 
@@ -4780,7 +4783,8 @@  copy_type_recursive (struct objfile *objfile,
      if it did, the type might disappear unexpectedly.  */
   gdb_assert (TYPE_OBJFILE (type) == objfile);
 
-  pair.old = type;
+  struct type_pair pair (type, nullptr);
+
   slot = htab_find_slot (copied_types, &pair, INSERT);
   if (*slot != NULL)
     return ((struct type_pair *) *slot)->newobj;
@@ -4789,9 +4793,9 @@  copy_type_recursive (struct objfile *objfile,
 
   /* We must add the new type to the hash table immediately, in case
      we encounter this type again during a recursive call below.  */
-  stored = XOBNEW (&objfile->objfile_obstack, struct type_pair);
-  stored->old = type;
-  stored->newobj = new_type;
+  struct type_pair *stored
+    = new (&objfile->objfile_obstack) struct type_pair (type, new_type);
+
   *slot = stored;
 
   /* Copy the common fields of types.  For the main type, we simply