aboutsummaryrefslogtreecommitdiff
path: root/gdb/gdbarch.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@ericsson.com>2018-05-20 21:06:03 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2018-05-20 21:06:36 -0400
commit284a0e3cbffa92ee5c94065fcdd5a528482344fc (patch)
tree8b7ad3a53e77adf130a5f33ed306fe76d4ab0ff8 /gdb/gdbarch.c
parentb1aed5de0cc075ab5061453f88cedbf2d3e97ff6 (diff)
downloadgdb-284a0e3cbffa92ee5c94065fcdd5a528482344fc.zip
gdb-284a0e3cbffa92ee5c94065fcdd5a528482344fc.tar.gz
gdb-284a0e3cbffa92ee5c94065fcdd5a528482344fc.tar.bz2
Introduce obstack_new, poison other "typed" obstack functions
Since we use obstacks with objects that are not default constructible, we sometimes need to manually call the constructor by hand using placement new: foo *f = obstack_alloc (obstack, sizeof (foo)); f = new (f) foo; It's possible to use allocate_on_obstack instead, but there are types that we sometimes want to allocate on an obstack, and sometimes on the regular heap. This patch introduces a utility to make this pattern simpler if allocate_on_obstack is not an option: foo *f = obstack_new<foo> (obstack); Right now there's only one usage (in tdesc_data_init). To help catch places where we would forget to call new when allocating such an object on an obstack, this patch also poisons some other methods of allocating an instance of a type on an obstack: - OBSTACK_ZALLOC/OBSTACK_CALLOC - XOBNEW/XOBNEW - GDBARCH_OBSTACK_ZALLOC/GDBARCH_OBSTACK_CALLOC Unfortunately, there's no way to catch wrong usages of obstack_alloc. By pulling on that string though, it tripped on allocating struct template_symbol using OBSTACK_ZALLOC. The criterion currently used to know whether it's safe to "malloc" an instance of a struct is whether it is a POD. Because it inherits from struct symbol, template_symbol is not a POD. This criterion is a bit too strict however, it should still safe to allocate memory for a template_symbol and memset it to 0. We didn't use is_trivially_constructible as the criterion in the first place only because it is not available in gcc < 5. So here I considered two alternatives: 1. Relax that criterion to use std::is_trivially_constructible and add a bit more glue code to make it work with gcc < 5 2. Continue pulling on the string and change how the symbol structures are allocated and initialized I managed to do both, but I decided to go with #1 to keep this patch simpler and more focused. When building with a compiler that does not have is_trivially_constructible, the check will just not be enforced. gdb/ChangeLog: * common/traits.h (HAVE_IS_TRIVIALLY_COPYABLE): Define if compiler supports std::is_trivially_constructible. * common/poison.h: Include obstack.h. (IsMallocable): Define to is_trivially_constructible if the compiler supports it, define to true_type otherwise. (xobnew): New. (XOBNEW): Redefine. (xobnewvec): New. (XOBNEWVEC): Redefine. * gdb_obstack.h (obstack_zalloc): New. (OBSTACK_ZALLOC): Redefine. (obstack_calloc): New. (OBSTACK_CALLOC): Redefine. (obstack_new): New. * gdbarch.sh: Include gdb_obstack in gdbarch.h. (gdbarch_obstack): New declaration in gdbarch.h, definition in gdbarch.c. (GDBARCH_OBSTACK_CALLOC, GDBARCH_OBSTACK_ZALLOC): Use obstack_calloc/obstack_zalloc. (gdbarch_obstack_zalloc): Remove. * target-descriptions.c (tdesc_data_init): Use obstack_new.
Diffstat (limited to 'gdb/gdbarch.c')
-rw-r--r--gdb/gdbarch.c9
1 files changed, 2 insertions, 7 deletions
diff --git a/gdb/gdbarch.c b/gdb/gdbarch.c
index 82ac751..c430ebe 100644
--- a/gdb/gdbarch.c
+++ b/gdb/gdbarch.c
@@ -471,15 +471,10 @@ gdbarch_alloc (const struct gdbarch_info *info,
}
-/* Allocate extra space using the per-architecture obstack. */
-void *
-gdbarch_obstack_zalloc (struct gdbarch *arch, long size)
+obstack *gdbarch_obstack (gdbarch *arch)
{
- void *data = obstack_alloc (arch->obstack, size);
-
- memset (data, 0, size);
- return data;
+ return arch->obstack;
}
/* See gdbarch.h. */