From: "Sourceware to Gerrit sync (Code Review)" <gerrit@gnutoolchain-gerrit.osci.io>
To: Christian Biesinger <cbiesinger@google.com>, gdb-patches@sourceware.org
Cc: Tom Tromey <tromey@sourceware.org>,
Simon Marchi <simon.marchi@polymtl.ca>,
Luis Machado <luis.machado@linaro.org>
Subject: [pushed] Don't make an extra copy + allocation of the demangled name
Date: Fri, 25 Oct 2019 19:10:00 -0000 [thread overview]
Message-ID: <20191025191008.6CBB7238BA@gnutoolchain-gerrit.osci.io> (raw)
In-Reply-To: <gerrit.1571352433000.Ie6ad50e1e1e73509f55d756f0a437897bb93e3b0@gnutoolchain-gerrit.osci.io>
Sourceware to Gerrit sync has submitted this change.
Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/132
......................................................................
Don't make an extra copy + allocation of the demangled name
We can just keep around the malloc()-ed name we got from bfd and free
it later.
gdb/ChangeLog:
2019-10-25 Christian Biesinger <cbiesinger@google.com>
* symtab.c (struct demangled_name_entry): Change demangled name
to a unique_xmalloc_ptr<char>, now that we don't allocate it as
part of the struct anymore.
(symbol_set_names): No longer obstack allocate + copy the demangled
name, just store the allocated name from bfd.
Change-Id: Ie6ad50e1e1e73509f55d756f0a437897bb93e3b0
---
M gdb/ChangeLog
M gdb/symtab.c
2 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 84fb9aa..55c4647 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,11 @@
+2019-10-25 Christian Biesinger <cbiesinger@google.com>
+
+ * symtab.c (struct demangled_name_entry): Change demangled name
+ to a unique_xmalloc_ptr<char>, now that we don't allocate it as
+ part of the struct anymore.
+ (symbol_set_names): No longer obstack allocate + copy the demangled
+ name, just store the allocated name from bfd.
+
2019-10-25 Tom Tromey <tromey@adacore.com>
* dwarf2-frame.c (dwarf2_cie_table): Now a typedef.
diff --git a/gdb/symtab.c b/gdb/symtab.c
index 160a4c0..adf9e08 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -723,7 +723,7 @@
gdb::string_view mangled;
enum language language;
- char demangled[1];
+ gdb::unique_xmalloc_ptr<char> demangled;
};
/* Hash function for the demangled name hash. */
@@ -839,7 +839,7 @@
{
/* In Ada, we do the symbol lookups using the mangled name, so
we can save some space by not storing the demangled name. */
- if (!copy_name)
+ if (!copy_name && linkage_name_copy == linkage_name)
gsymbol->name = linkage_name;
else
{
@@ -880,20 +880,17 @@
if (*slot == NULL
/* A C version of the symbol may have already snuck into the table.
This happens to, e.g., main.init (__go_init_main). Cope. */
- || (gsymbol->language == language_go
- && (*slot)->demangled[0] == '\0'))
+ || (gsymbol->language == language_go && (*slot)->demangled == nullptr))
{
- char *demangled_name_ptr
- = symbol_find_demangled_name (gsymbol, linkage_name_copy);
- gdb::unique_xmalloc_ptr<char> demangled_name (demangled_name_ptr);
- int demangled_len = demangled_name ? strlen (demangled_name.get ()) : 0;
+ gdb::unique_xmalloc_ptr<char> demangled_name_ptr
+ (symbol_find_demangled_name (gsymbol, linkage_name_copy));
/* Suppose we have demangled_name==NULL, copy_name==0, and
linkage_name_copy==linkage_name. In this case, we already have the
mangled name saved, and we don't have a demangled name. So,
you might think we could save a little space by not recording
this in the hash table at all.
-
+
It turns out that it is actually important to still save such
an entry in the hash table, because storing this name gives
us better bcache hit rates for partial symbols. */
@@ -902,42 +899,33 @@
*slot
= ((struct demangled_name_entry *)
obstack_alloc (&per_bfd->storage_obstack,
- offsetof (struct demangled_name_entry, demangled)
- + demangled_len + 1));
+ sizeof (demangled_name_entry)));
new (*slot) demangled_name_entry
(gdb::string_view (linkage_name, len));
}
else
{
- char *mangled_ptr;
-
/* If we must copy the mangled name, put it directly after
- the demangled name so we can have a single
- allocation. */
+ the struct so we can have a single allocation. */
*slot
= ((struct demangled_name_entry *)
obstack_alloc (&per_bfd->storage_obstack,
- offsetof (struct demangled_name_entry, demangled)
- + len + demangled_len + 2));
- mangled_ptr = &((*slot)->demangled[demangled_len + 1]);
+ sizeof (demangled_name_entry) + len + 1));
+ char *mangled_ptr = reinterpret_cast<char *> (*slot + 1);
strcpy (mangled_ptr, linkage_name_copy);
new (*slot) demangled_name_entry
(gdb::string_view (mangled_ptr, len));
}
+ (*slot)->demangled = std::move (demangled_name_ptr);
(*slot)->language = gsymbol->language;
-
- if (demangled_name != NULL)
- strcpy ((*slot)->demangled, demangled_name.get ());
- else
- (*slot)->demangled[0] = '\0';
}
else if (gsymbol->language == language_unknown
|| gsymbol->language == language_auto)
gsymbol->language = (*slot)->language;
gsymbol->name = (*slot)->mangled.data ();
- if ((*slot)->demangled[0] != '\0')
- symbol_set_demangled_name (gsymbol, (*slot)->demangled,
+ if ((*slot)->demangled != nullptr)
+ symbol_set_demangled_name (gsymbol, (*slot)->demangled.get (),
&per_bfd->storage_obstack);
else
symbol_set_demangled_name (gsymbol, NULL, &per_bfd->storage_obstack);
--
Gerrit-Project: binutils-gdb
Gerrit-Branch: master
Gerrit-Change-Id: Ie6ad50e1e1e73509f55d756f0a437897bb93e3b0
Gerrit-Change-Number: 132
Gerrit-PatchSet: 4
Gerrit-Owner: Christian Biesinger <cbiesinger@google.com>
Gerrit-Reviewer: Luis Machado <luis.machado@linaro.org>
Gerrit-Reviewer: Simon Marchi <simon.marchi@polymtl.ca>
Gerrit-Reviewer: Tom Tromey <tromey@sourceware.org>
Gerrit-MessageType: merged
next prev parent reply other threads:[~2019-10-25 19:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 22:47 [review] " Christian Biesinger (Code Review)
2019-10-21 23:19 ` Luis Machado (Code Review)
2019-10-22 4:32 ` Simon Marchi (Code Review)
2019-10-22 19:04 ` [review v2] " Christian Biesinger (Code Review)
2019-10-22 19:04 ` Christian Biesinger (Code Review)
2019-10-22 19:27 ` Simon Marchi (Code Review)
2019-10-23 16:51 ` [review v3] " Christian Biesinger (Code Review)
2019-10-25 18:23 ` Tom Tromey (Code Review)
2019-10-25 18:24 ` Tom Tromey (Code Review)
2019-10-25 19:10 ` Sourceware to Gerrit sync (Code Review) [this message]
2019-10-25 19:10 ` Christian Biesinger (Code Review)
2019-10-25 19:10 ` [pushed] " Sourceware to Gerrit sync (Code Review)
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=20191025191008.6CBB7238BA@gnutoolchain-gerrit.osci.io \
--to=gerrit@gnutoolchain-gerrit.osci.io \
--cc=cbiesinger@google.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@linaro.org \
--cc=noreply@gnutoolchain-gerrit.osci.io \
--cc=simon.marchi@polymtl.ca \
--cc=tromey@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