Commit Graph

7 Commits

Author SHA1 Message Date
Simon Marchi 184cde7552 Fix copy-pasto, allocate objfile_per_bfd_storage with obstack_new
I realized after pushing that I made a copy-pasto, I had:

  # define HAVE_IS_TRIVIALLY_COPYABLE 1

instead of

  # define HAVE_IS_TRIVIALLY_CONSTRUCTIBLE 1

with the consequence that IsMallocable was always std::true_type (and
was therefore not enforcing anything).  Fixing that mistake triggered a
build failure:

/home/simark/src/binutils-gdb/gdb/objfiles.c:150:12:   required from here
/home/simark/src/binutils-gdb/gdb/common/poison.h:228:3: error: static assertion failed: Trying to use XOBNEW with a non-POD data type.

I am not sure why I did not see this when I originally wrote the patch
(but I saw and fixed other failures).  In any case, I swapped XOBNEW
with obstack_new to get rid of it.

Regtested on the buildbot.

gdb/ChangeLog:

	* common/traits.h (HAVE_IS_TRIVIALLY_COPYABLE): Rename the wrong
	instance to...
	(HAVE_IS_TRIVIALLY_CONSTRUCTIBLE): ... this.
	* objfiles.c (get_objfile_bfd_data): Allocate
	objfile_per_bfd_storage with obstack_new when allocating on
	obstack.
2018-05-20 23:19:35 -04:00
Simon Marchi 284a0e3cbf 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.
2018-05-20 21:06:36 -04:00
Joel Brobecker e2882c8578 Update copyright year range in all GDB files
gdb/ChangeLog:

        Update copyright year range in all GDB files
2018-01-02 07:38:06 +04:00
Pedro Alves debed3db48 Fix build on gcc < 5 (std::is_trivially_copyable missing)
Ref: https://sourceware.org/ml/gdb-patches/2017-04/msg00660.html

Simply skip the poisoning on older compilers.

gdb/ChangeLog:
2017-04-25  Pedro Alves  <palves@redhat.com>

	* common/poison.h [!HAVE_IS_TRIVIALLY_COPYABLE] (IsRelocatable)
	(BothAreRelocatable, memcopy, memmove): Don't define.
	* common/traits.h (__has_feature, HAVE_IS_TRIVIALLY_COPYABLE): New
	macros.
2017-04-25 10:58:57 +01:00
Pedro Alves b0b92aeb38 Poison non-POD memset & non-trivially-copyable memcpy/memmove
This patch catches invalid initialization of non-POD types with
memset, at compile time.

This is what I used to catch the problems fixed by the previous
patches in the series:

  $ make -k 2>&1 | grep "deleted function"
  src/gdb/breakpoint.c:951:53: error: use of deleted function ‘void* memset(T*, int, size_t) [with T = bp_location; <template-parameter-1-2> = void; size_t = long unsigned int]’
  src/gdb/breakpoint.c:7325:32: error: use of deleted function ‘void* memset(T*, int, size_t) [with T = bp_location; <template-parameter-1-2> = void; size_t = long unsigned int]’
  src/gdb/btrace.c:1153:42: error: use of deleted function ‘void* memset(T*, int, size_t) [with T = btrace_insn; <template-parameter-1-2> = void; size_t = long unsigned int]’
...

gdb/ChangeLog:
2017-04-25  Pedro Alves  <palves@redhat.com>

	* common/common-defs.h: Include "common/poison.h".
	* common/function-view.h: (Not, Or, Requires): Move to traits.h
	and adjust.
	* common/poison.h: New file.
	* common/traits.h: Include <type_traits>.
	(Not, Or, Requires): New, moved from common/function-view.h.
2017-04-25 01:46:19 +01:00
Pedro Alves 22796e972f More gdb::optional features
Currently we can't use gdb::optional<T> as function return type,
because gdb::optional's copy ctor is deleted.  For example, with:

  gdb::optional<int> function ()
  {
    gdb::optional<int> opt;
    ....
    return opt;

we get:

  src/gdb/foo.c: In function ‘gdb::optional<int> foo()’:
  src/gdb/foo.c:75:10: error: use of deleted function ‘gdb::optional<T>::optional(const gdb::optional<T>&) [with T = int]’
     return opt;
	    ^
  In file included from src/gdb/foo.c:68:0:
  src/gdb/common/gdb_optional.h:53:3: note: declared here
     optional (const optional &other) = delete;
     ^

I started by fixing that, and then ran into another missing feature,
also fixed by this patch.

The next feature I'm missing most from gdb::optional<T> compared to
std::optional<T> is construction/move/assignment from a T, instead of
having to default construct an gdb::optional and then use
optional::emplace(....).

For example:
  gdb::optional<std::string> function ()
  {
    gdb::optional<std::string> opt;
    std::string str;
    ...
    opt.emplace (std::move (str));
    return opt;
vs
  gdb::optional<std::string> function ()
  {
    std::string str;
    ...
    return str;

The copy/move ctor/assign methods weren't initialy implemented because
std::optional supports construction from a type U if U is convertible
to T too, and has rules to decide whether the ctors are
explicit/implicit based on that, and rules for whether the ctor should
be trivial or not, etc., which leads to a much more complicated
implementation.

If we stick to supporting copy/move construction/assignment of/to an
optional<T> from exactly only optional<T> and T, then all that
conversion-related complication disappears, and we still gain
convenience in most use cases.

The patch also makes emplace return a reference to the constructor
object, per C++17 std::optional, and adds a reset method, againt
because std::optional has one and it's trivial to support it.  These
two changes are a requirement of the gdb::optional unit testing patch
that will follow.

gdb/ChangeLog:
2017-04-18  Pedro Alves  <palves@redhat.com>

	* common/gdb_optional.h: Include common/traits.h.
	(in_place_t): New type.
	(in_place): New constexpr variable.
	(optional::optional): Remove member initialization of
	m_instantiated.
	(optional::optional(in_place_t...)): New constructor.
	(optional::~optional): Use reset.
	(optional::optional(const optional&)): New.
	(optional::optional(const optional&&)): New.
	(optional::optional(T &)): New.
	(optional::optional(T &&)): New.
	(operator::operator=(const optional &)): New.
	(operator::operator=(optional &&)): New.
	(operator::operator= (const T &))
	(operator::operator= (T &&))
	(operator::emplace (Args &&... args)): Return a T&.  Use reset.
	(operator::reset): New.
	(operator::m_instantiated):: Add in-class initializer.
	* common/traits.h: Include <type_traits>.
	(struct And): New types.
2017-04-18 23:48:41 +01:00
Pedro Alves 9c54172556 Make sect_offset and cu_offset strong typedefs instead of structs
A while ago, back when GDB was a C program, the sect_offset and
cu_offset types were made structs in order to prevent incorrect mixing
of those offsets.  Now that we require C++11, we can make them
integers again, while keeping the safety, by exploiting "enum class".
We can add a bit more safety, even, by defining operators that the
types _should_ support, helping making the suspicious uses stand out
more.

Getting at the underlying type is done with the new to_underlying
function added by the previous patch, which also helps better spot
where do we need to step out of the safety net.  Mostly, that's around
parsing the DWARF, and when we print the offset for complaint/debug
purposes.  But there are other occasional uses.

Since we have to define the sect_offset/cu_offset types in a header
anyway, I went ahead and generalized/library-fied the idea of "offset"
types, making it trivial to add more such types if we find a use.  See
common/offset-type.h and the DEFINE_OFFSET_TYPE macro.

I needed a couple generaly-useful preprocessor bits (e.g., yet another
CONCAT implementation), so I started a new common/preprocessor.h file.

I included units tests covering the "offset" types API.  These are
mostly compile-time tests, using SFINAE to check that expressions that
shouldn't compile (e.g., comparing unrelated offset types) really are
invalid and would fail to compile.  This same idea appeared in my
pending enum-flags revamp from a few months ago (though this version
is a bit further modernized compared to what I had posted), and I plan
on reusing the "check valid expression" bits added here in that
series, so I went ahead and defined the CHECK_VALID_EXPR macro in its
own header -- common/valid-expr.h.  I think that's nicer regardless.

I was borderline between calling the new types "offset" types, or
"index" types, BTW.  I stuck with "offset" simply because that's what
we're already calling them, mostly.

gdb/ChangeLog:
2017-04-04  Pedro Alves  <palves@redhat.com>

	* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
	unittests/offset-type-selftests.c.
	(SUBDIR_UNITTESTS_OBS): Add offset-type-selftests.o.
	* common/offset-type.h: New file.
	* common/preprocessor.h: New file.
	* common/traits.h: New file.
	* common/valid-expr.h: New file.
	* dwarf2expr.c: Include "common/underlying.h".  Adjust to use
	sect_offset and cu_offset strong typedefs throughout.
	* dwarf2expr.h: Adjust to use sect_offset and cu_offset strong
	typedefs throughout.
	* dwarf2loc.c: Include "common/underlying.h".  Adjust to use
	sect_offset and cu_offset strong typedefs throughout.
	* dwarf2read.c: Adjust to use sect_offset and cu_offset strong
	typedefs throughout.
	* gdbtypes.h: Include "common/offset-type.h".
	(cu_offset): Now an offset type (strong typedef) instead of a
	struct.
	(sect_offset): Likewise.
	(union call_site_parameter_u): Rename "param_offset" field to
	"param_cu_off".
	* unittests/offset-type-selftests.c: New file.
2017-04-04 20:03:26 +01:00