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] Re-write partial_die_info allocation in load_partial_dies
Date: Mon, 26 Feb 2018 15:54:00 -0000	[thread overview]
Message-ID: <cd9983dd5f16803aa60e9fe1692b7e6716ac3927@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT cd9983dd5f16803aa60e9fe1692b7e6716ac3927 ***

Author: Yao Qi <yao.qi@linaro.org>
Branch: master
Commit: cd9983dd5f16803aa60e9fe1692b7e6716ac3927

Re-write partial_die_info allocation in load_partial_dies

load_partial_dies has a "while (1)" loop to visit each die, and create
partial_die_info if needed in each iteration, like this,

  part_die = XOBNEW (&cu->comp_unit_obstack, struct partial_die_info);

  while (1)
   {
      if (foo1) continue;

      if (foo2) continue;

      read_partial_die (, , part_die, ,);

      ....
      part_die = XOBNEW (&cu->comp_unit_obstack, struct partial_die_info);
   };

the code was written in a way that spaces are allocated on necessary on
cu->comp_unit_obstack.  I want to class-fy partial_die_info, but
partial_die_info ctor can't follow XOBNEW immediately, so this patch
rewrite this loop to:

  while (1)
   {
      if (foo1) continue;

      if (foo2) continue;

      struct partial_die_info pdi;
      read_partial_die (, , &pdi, ,);

      part_die = XOBNEW (&cu->comp_unit_obstack, struct partial_die_info);
      memcpy (part_die, &pdi, sizeof (pdi));
   };

we create a local variable pdi, if we need it, call XOBNEW, and copy.
This also reduce one XOBNEW call.  I measured the number of XOBNEW call in
load_partial_dies when gdb reads dwarf2read.o, without this patch, it is
18827, and with this patch, it is 18826.

gdb:

2018-026-26  Yao Qi  <yao.qi@linaro.org>

	* dwarf2read.c (load_partial_dies): Move the location of XOBNEW.


             reply	other threads:[~2018-02-26 15:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 15:54 sergiodj+buildbot [this message]
2018-02-26 15:54 ` Failures on RHEL-s390x-m64, branch master sergiodj+buildbot
2018-02-26 15:58 ` Failures on Fedora-i686, " sergiodj+buildbot
2018-02-26 16:01 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2018-02-26 16:21 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot
2018-02-26 16:34 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot
2018-02-26 16:40 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2018-02-26 16:42 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2018-02-27  0:15 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot
2018-02-27  1:01 ` Failures on Ubuntu-AArch32-native-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=cd9983dd5f16803aa60e9fe1692b7e6716ac3927@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).