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;
}
next prev parent 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