public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: sergiodj+buildbot@sergiodj.net
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] Introduce obstack_new, poison other "typed" obstack functions
Date: Mon, 21 May 2018 01:51:00 -0000	[thread overview]
Message-ID: <284a0e3cbffa92ee5c94065fcdd5a528482344fc@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT 284a0e3cbffa92ee5c94065fcdd5a528482344fc ***

Author: Simon Marchi <simon.marchi@ericsson.com>
Branch: master
Commit: 284a0e3cbffa92ee5c94065fcdd5a528482344fc

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.


             reply	other threads:[~2018-05-21  1:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21  1:51 sergiodj+buildbot [this message]
2018-05-21  1:51 ` Failures on Debian-s390x-m64, branch master sergiodj+buildbot
2018-05-21  1:52 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot
2018-05-28 15:37 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot
2018-05-28 15:58 ` Failures on Fedora-i686, " sergiodj+buildbot
2018-05-28 18:12 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot
2018-05-28 18:25 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-w64-mingw32, branch master *** BREAKAGE *** sergiodj+buildbot
2018-07-27  1:33 ` Failures on Ubuntu-AArch32-m32, branch master sergiodj+buildbot
2018-07-27  5:00 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=284a0e3cbffa92ee5c94065fcdd5a528482344fc@gdb-build \
    --to=sergiodj+buildbot@sergiodj.net \
    --cc=gdb-testers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).