Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: David Carlton <carlton@math.stanford.edu>
To: Elena Zannoni <ezannoni@redhat.com>
Cc: gdb-patches@sources.redhat.com, Jim Blandy <jimb@redhat.com>
Subject: Re: [rfa] fix pr java/1039
Date: Mon, 14 Apr 2003 20:01:00 -0000	[thread overview]
Message-ID: <ro1he90etm1.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <ro1llycetps.fsf@jackfruit.Stanford.EDU>

On 14 Apr 2003 12:59:11 -0700, David Carlton <carlton@math.stanford.edu> said:
> On Mon, 14 Apr 2003 13:55:21 -0400, Elena Zannoni <ezannoni@redhat.com> said:

>> could you do it in 2 passes? First pass with the format changes and
>> the variables renaming. Second pass with the actual juicy Java
>> fixes.

> Good idea; I've committed it as you suggest.  Here's the first patch,
> that only renames things and tidies up the format a bit; I'll send the
> second patch in a sec.

Here's the second one, that actually fixes the bug.

David Carlton
carlton@math.stanford.edu

2003-04-14  David Carlton  <carlton@math.stanford.edu>

	* symtab.c (symbol_set_names): Add prefix when storing Java names
	in hash table.  Fix for PR java/1039.

Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.100
diff -u -p -r1.100 symtab.c
--- symtab.c	14 Apr 2003 19:55:27 -0000	1.100
+++ symtab.c	14 Apr 2003 19:56:05 -0000
@@ -490,6 +490,25 @@ symbol_find_demangled_name (struct gener
    LINKAGE_NAME is copied, so the pointer can be discarded after
    calling this function.  */
 
+/* We have to be careful when dealing with Java names: when we run
+   into a Java minimal symbol, we don't know it's a Java symbol, so it
+   gets demangled as a C++ name.  This is unfortunate, but there's not
+   much we can do about it: but when demangling partial symbols and
+   regular symbols, we'd better not reuse the wrong demangled name.
+   (See PR gdb/1039.)  We solve this by putting a distinctive prefix
+   on Java names when storing them in the hash table.  */
+
+/* FIXME: carlton/2003-03-13: This is an unfortunate situation.  I
+   don't mind the Java prefix so much: different languages have
+   different demangling requirements, so it's only natural that we
+   need to keep language data around in our demangling cache.  But
+   it's not good that the minimal symbol has the wrong demangled name.
+   Unfortunately, I can't think of any easy solution to that
+   problem.  */
+
+#define JAVA_PREFIX "##JAVA$$"
+#define JAVA_PREFIX_LEN 8
+
 void
 symbol_set_names (struct general_symbol_info *gsymbol,
 		  const char *linkage_name, int len, struct objfile *objfile)
@@ -497,30 +516,52 @@ symbol_set_names (struct general_symbol_
   char **slot;
   /* A 0-terminated copy of the linkage name.  */
   const char *linkage_name_copy;
+  /* A copy of the linkage name that might have a special Java prefix
+     added to it, for use when looking names up in the hash table.  */
+  const char *lookup_name;
+  /* The length of lookup_name.  */
+  int lookup_len;
 
   if (objfile->demangled_names_hash == NULL)
     create_demangled_names_hash (objfile);
 
   /* The stabs reader generally provides names that are not
      NUL-terminated; most of the other readers don't do this, so we
-     can just use the given copy.  */
-  if (linkage_name[len] != '\0')
+     can just use the given copy, unless we're in the Java case.  */
+  if (gsymbol->language == language_java)
+    {
+      char *alloc_name;
+      lookup_len = len + JAVA_PREFIX_LEN;
+
+      alloc_name = alloca (lookup_len + 1);
+      memcpy (alloc_name, JAVA_PREFIX, JAVA_PREFIX_LEN);
+      memcpy (alloc_name + JAVA_PREFIX_LEN, linkage_name, len);
+      alloc_name[lookup_len] = '\0';
+
+      lookup_name = alloc_name;
+      linkage_name_copy = alloc_name + JAVA_PREFIX_LEN;
+    }
+  else if (linkage_name[len] != '\0')
     {
       char *alloc_name;
+      lookup_len = len;
 
-      alloc_name = alloca (len + 1);
+      alloc_name = alloca (lookup_len + 1);
       memcpy (alloc_name, linkage_name, len);
-      alloc_name[len] = '\0';
+      alloc_name[lookup_len] = '\0';
 
+      lookup_name = alloc_name;
       linkage_name_copy = alloc_name;
     }
   else
     {
+      lookup_len = len;
+      lookup_name = linkage_name;
       linkage_name_copy = linkage_name;
     }
 
   slot = (char **) htab_find_slot (objfile->demangled_names_hash,
-				   linkage_name_copy, INSERT);
+				   lookup_name, INSERT);
 
   /* If this name is not in the hash table, add it.  */
   if (*slot == NULL)
@@ -533,21 +574,21 @@ symbol_set_names (struct general_symbol_
 	 Otherwise, just place a second zero byte after the end of the mangled
 	 name.  */
       *slot = obstack_alloc (&objfile->symbol_obstack,
-			     len + demangled_len + 2);
-      memcpy (*slot, linkage_name_copy, len + 1);
+			     lookup_len + demangled_len + 2);
+      memcpy (*slot, lookup_name, lookup_len + 1);
       if (demangled_name != NULL)
 	{
-	  memcpy (*slot + len + 1, demangled_name, demangled_len + 1);
+	  memcpy (*slot + lookup_len + 1, demangled_name, demangled_len + 1);
 	  xfree (demangled_name);
 	}
       else
-	(*slot)[len + 1] = '\0';
+	(*slot)[lookup_len + 1] = '\0';
     }
 
-  gsymbol->name = *slot;
-  if ((*slot)[len + 1] != '\0')
+  gsymbol->name = *slot + lookup_len - len;
+  if ((*slot)[lookup_len + 1] != '\0')
     gsymbol->language_specific.cplus_specific.demangled_name
-      = &(*slot)[len + 1];
+      = &(*slot)[lookup_len + 1];
   else
     gsymbol->language_specific.cplus_specific.demangled_name = NULL;
 }


  reply	other threads:[~2003-04-14 20:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-14  5:23 David Carlton
2003-03-14 14:47 ` Daniel Jacobowitz
2003-03-14 17:26   ` David Carlton
2003-04-14 17:51 ` Elena Zannoni
2003-04-14 19:59   ` David Carlton
2003-04-14 20:01     ` David Carlton [this message]
2003-03-14 19:10 Michael Elizabeth Chastain

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=ro1he90etm1.fsf@jackfruit.Stanford.EDU \
    --to=carlton@math.stanford.edu \
    --cc=ezannoni@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    /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