public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: gdb-buildbot@sergiodj.net
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] Don't make an extra copy + allocation of the demangled name
Date: Fri, 25 Oct 2019 19:38:00 -0000	[thread overview]
Message-ID: <5396ae1717ade2dbbdb73790eafcdd885045860b@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT 5396ae1717ade2dbbdb73790eafcdd885045860b ***

commit 5396ae1717ade2dbbdb73790eafcdd885045860b
Author:     Christian Biesinger <cbiesinger@google.com>
AuthorDate: Sun Oct 13 06:56:58 2019 -0500
Commit:     Christian Biesinger <cbiesinger@google.com>
CommitDate: Fri Oct 25 14:09:02 2019 -0500

    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

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 84fb9aa822..55c46473ab 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 160a4c08e9..adf9e08067 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -723,7 +723,7 @@ struct demangled_name_entry
 
   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 @@ symbol_set_names (struct general_symbol_info *gsymbol,
     {
       /* 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 @@ symbol_set_names (struct general_symbol_info *gsymbol,
   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 @@ symbol_set_names (struct general_symbol_info *gsymbol,
 	  *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);


             reply	other threads:[~2019-10-25 19:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 19:38 gdb-buildbot [this message]
2019-10-25 19:38 ` Failures on Ubuntu-Aarch64-m64, branch master gdb-buildbot
2019-10-25 19:52 ` Failures on Ubuntu-Aarch64-native-gdbserver-m64, " gdb-buildbot
2019-11-13 12:00 ` Failures on Fedora-i686, " gdb-buildbot
2019-11-13 12:10 ` Failures on Fedora-x86_64-cc-with-index, " gdb-buildbot
2019-11-13 12:49 ` Failures on Fedora-x86_64-m32, " gdb-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=5396ae1717ade2dbbdb73790eafcdd885045860b@gdb-build \
    --to=gdb-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).