From: "Christian Biesinger (Code Review)" <gerrit@gnutoolchain-gerrit.osci.io>
To: Christian Biesinger <cbiesinger@google.com>,
Luis Machado <luis.machado@linaro.org>,
gdb-patches@sourceware.org
Cc: Tom Tromey <tromey@sourceware.org>
Subject: [review v3] Only make a nullterminated string if we need to
Date: Mon, 28 Oct 2019 18:51:00 -0000 [thread overview]
Message-ID: <20191028185119.39FE920AF6@gnutoolchain-gerrit.osci.io> (raw)
In-Reply-To: <gerrit.1571783424000.I183302e1f51483ff6dff0fd5c3b0f32f0f04a5d2@gnutoolchain-gerrit.osci.io>
Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/222
......................................................................
Only make a nullterminated string if we need to
As of 7bb43059820c5febb4509b15202a93efde442bc6, we no longer need
a nullterminated linkage_name to look up the entry in the hash table.
So this patch makes it so we only make the copy if the entry was
not found.
By auditing all callers of symbol_set_names, I found out that all cases
where the string may not be nullterminated already pass true for COPY_NAME.
So here, I am documenting that as a requirement and am removing the code
that relies on undefined behavior in symbol_set_names (it accessed the string
past the provided length to check for nulltermination). Note that the Ada
case at the beginning of symbol_set_names was already relying on this.
gdb/ChangeLog:
2019-10-28 Christian Biesinger <cbiesinger@google.com>
* symtab.h (symbol_set_names): Document that copy_name must be
set to true for non-nullterminated strings.
* symtab.c (symbol_set_names): Only make a nullterminated copy of
linkage_name if the entry was not found and we need to demangle.
Change-Id: I183302e1f51483ff6dff0fd5c3b0f32f0f04a5d2
---
M gdb/symtab.c
M gdb/symtab.h
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/gdb/symtab.c b/gdb/symtab.c
index 79c5fde..674ab2e 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -832,8 +832,6 @@
struct objfile_per_bfd_storage *per_bfd)
{
struct demangled_name_entry **slot;
- /* A 0-terminated copy of the linkage name. */
- const char *linkage_name_copy;
if (gsymbol->language == language_ada)
{
@@ -858,20 +856,7 @@
if (per_bfd->demangled_names_hash == NULL)
create_demangled_names_hash (per_bfd);
- if (linkage_name[len] != '\0')
- {
- char *alloc_name;
-
- alloc_name = (char *) alloca (len + 1);
- memcpy (alloc_name, linkage_name, len);
- alloc_name[len] = '\0';
-
- linkage_name_copy = alloc_name;
- }
- else
- linkage_name_copy = linkage_name;
-
- struct demangled_name_entry entry (gdb::string_view (linkage_name_copy, len));
+ struct demangled_name_entry entry (gdb::string_view (linkage_name, len));
slot = ((struct demangled_name_entry **)
htab_find_slot (per_bfd->demangled_names_hash.get (),
&entry, INSERT));
@@ -882,6 +867,22 @@
This happens to, e.g., main.init (__go_init_main). Cope. */
|| (gsymbol->language == language_go && (*slot)->demangled == nullptr))
{
+ /* A 0-terminated copy of the linkage name. Callers must set COPY_NAME
+ to true if the string might not be nullterminated. */
+ const char *linkage_name_copy;
+ if (copy_name)
+ {
+ char *alloc_name;
+
+ alloc_name = (char *) alloca (len + 1);
+ memcpy (alloc_name, linkage_name, len);
+ alloc_name[len] = '\0';
+
+ linkage_name_copy = alloc_name;
+ }
+ else
+ linkage_name_copy = linkage_name;
+
gdb::unique_xmalloc_ptr<char> demangled_name_ptr
(symbol_find_demangled_name (gsymbol, linkage_name_copy));
@@ -894,7 +895,7 @@
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. */
- if (!copy_name && linkage_name_copy == linkage_name)
+ if (!copy_name)
{
*slot
= ((struct demangled_name_entry *)
@@ -912,7 +913,8 @@
obstack_alloc (&per_bfd->storage_obstack,
sizeof (demangled_name_entry) + len + 1));
char *mangled_ptr = reinterpret_cast<char *> (*slot + 1);
- strcpy (mangled_ptr, linkage_name_copy);
+ memcpy (mangled_ptr, linkage_name, len);
+ mangled_ptr [len] = '\0';
new (*slot) demangled_name_entry
(gdb::string_view (mangled_ptr, len));
}
diff --git a/gdb/symtab.h b/gdb/symtab.h
index 5300383..131a74d 100644
--- a/gdb/symtab.h
+++ b/gdb/symtab.h
@@ -504,7 +504,8 @@
(symbol)->ginfo.name = (linkage_name)
/* Set the linkage and natural names of a symbol, by demangling
- the linkage name. */
+ the linkage name. If linkage_name may not be nullterminated,
+ copy_name must be set to true. */
#define SYMBOL_SET_NAMES(symbol,linkage_name,len,copy_name,objfile) \
symbol_set_names (&(symbol)->ginfo, linkage_name, len, copy_name, \
(objfile)->per_bfd)
--
Gerrit-Project: binutils-gdb
Gerrit-Branch: master
Gerrit-Change-Id: I183302e1f51483ff6dff0fd5c3b0f32f0f04a5d2
Gerrit-Change-Number: 222
Gerrit-PatchSet: 3
Gerrit-Owner: Christian Biesinger <cbiesinger@google.com>
Gerrit-Reviewer: Christian Biesinger <cbiesinger@google.com>
Gerrit-Reviewer: Luis Machado <luis.machado@linaro.org>
Gerrit-CC: Tom Tromey <tromey@sourceware.org>
Gerrit-MessageType: newpatchset
next prev parent reply other threads:[~2019-10-28 18:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 22:30 [review] " Christian Biesinger (Code Review)
2019-10-25 17:59 ` Tom Tromey (Code Review)
2019-10-25 18:04 ` Christian Biesinger (Code Review)
2019-10-25 20:02 ` [review v2] " Christian Biesinger (Code Review)
2019-10-25 20:08 ` Christian Biesinger (Code Review)
2019-10-28 18:51 ` Christian Biesinger (Code Review) [this message]
2019-10-28 19:01 ` [review v4] " Christian Biesinger (Code Review)
2019-10-29 19:10 ` Tom Tromey (Code Review)
2019-10-29 19:28 ` [pushed] " Sourceware to Gerrit sync (Code Review)
2019-10-29 19:28 ` 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=20191028185119.39FE920AF6@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=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