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.
next 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: linkBe 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).