From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sources.redhat.com
Cc: mec.gnu@mindspring.com
Subject: Re: [rfa] Use SYMBOL_SET_NAMES in hpread
Date: Mon, 16 Feb 2004 21:27:00 -0000 [thread overview]
Message-ID: <20040216212741.GA17493@nevyn.them.org> (raw)
In-Reply-To: <20040216212109.GB17141@nevyn.them.org>
On Mon, Feb 16, 2004 at 04:21:09PM -0500, Daniel Jacobowitz wrote:
> Make hpread use SYMBOL_SET_NAMES. It contained some fallback code to
> use the debug info if demangling failed; I've disabled it, because from
> the description it sounds like the right thing to do would be to fix
> the demangler instead. I can't tell whether the code is currently used
> or not, so I would appreciate HP/UX testing for this patch.
>
> Michael, could you do that, please?
I apologize, the diff was corrupted.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
2004-02-16 Daniel Jacobowitz <drow@mvista.com>
* hpread.c (hpread_process_one_debug_symbol): Use SYMBOL_SET_NAMES
and rely on the demangler.
--- hpread.c 7 Feb 2004 23:13:47 -0000 1.45
+++ hpread.c 15 Feb 2004 23:56:30 -0000
@@ -5096,5 +5093,6 @@ hpread_process_one_debug_symbol (union d
struct symbol *sym;
struct context_stack *new;
char *class_scope_name;
+ char *set_name;
/* Allocate one GDB debug symbol and fill in some default values. */
@@ -5278,37 +5277,25 @@ hpread_process_one_debug_symbol (union d
if ((dn_bufp->dfunc.language == HP_LANGUAGE_CPLUSPLUS) &&
dn_bufp->dfunc.alias && /* has an alias */
*(char *) (VT (objfile) + dn_bufp->dfunc.alias)) /* not a null string */
- DEPRECATED_SYMBOL_NAME (sym) = VT (objfile) + dn_bufp->dfunc.alias;
+ set_name = VT (objfile) + dn_bufp->dfunc.alias;
else
- DEPRECATED_SYMBOL_NAME (sym) = VT (objfile) + dn_bufp->dfunc.name;
+ set_name = VT (objfile) + dn_bufp->dfunc.name;
/* Special hack to get around HP compilers' insistence on
* reporting "main" as "_MAIN_" for C/C++ */
- if ((strcmp (DEPRECATED_SYMBOL_NAME (sym), "_MAIN_") == 0) &&
+ if ((strcmp (set_name, "_MAIN_") == 0) &&
(strcmp (VT (objfile) + dn_bufp->dfunc.name, "main") == 0))
- DEPRECATED_SYMBOL_NAME (sym) = VT (objfile) + dn_bufp->dfunc.name;
+ set_name = VT (objfile) + dn_bufp->dfunc.name;
- /* The SYMBOL_CPLUS_DEMANGLED_NAME field is expected to
- * be the demangled name.
- */
+ SYMBOL_SET_NAMES (sym, set_name, strlen (set_name), objfile);
+#if 0
+ /* NOTE drow/2004-02-08: The following code is terribly bogus. The
+ demangler should be fixed instead. */
if (dn_bufp->dfunc.language == HP_LANGUAGE_CPLUSPLUS)
{
- /* SYMBOL_INIT_DEMANGLED_NAME is a macro which winds up
- * calling the demangler in libiberty (cplus_demangle()) to
- * do the job. This generally does the job, even though
- * it's intended for the GNU compiler and not the aCC compiler
- * Note that SYMBOL_INIT_DEMANGLED_NAME calls the
- * demangler with arguments DMGL_PARAMS | DMGL_ANSI.
- * Generally, we don't want params when we display
- * a demangled name, but when I took out the DMGL_PARAMS,
- * some things broke, so I'm leaving it in here, and
- * working around the issue in stack.c. - RT
- */
- SYMBOL_INIT_DEMANGLED_NAME (sym, &objfile->objfile_obstack);
- if ((DEPRECATED_SYMBOL_NAME (sym) == VT (objfile) + dn_bufp->dfunc.alias) &&
- (!SYMBOL_CPLUS_DEMANGLED_NAME (sym)))
+ if (set_name == VT (objfile) + dn_bufp->dfunc.alias
+ && !SYMBOL_CPLUS_DEMANGLED_NAME (sym))
{
-
/* Well, the symbol name is mangled, but the
* demangler in libiberty failed so the demangled
* field is still NULL. Try to
@@ -5334,6 +5321,7 @@ hpread_process_one_debug_symbol (union d
}
}
}
+#endif
/* Add the function symbol to the list of symbols in this blockvector */
if (dn_bufp->dfunc.global)
@@ -5396,36 +5384,25 @@ hpread_process_one_debug_symbol (union d
if ((dn_bufp->ddocfunc.language == HP_LANGUAGE_CPLUSPLUS) &&
dn_bufp->ddocfunc.alias && /* has an alias */
*(char *) (VT (objfile) + dn_bufp->ddocfunc.alias)) /* not a null string */
- DEPRECATED_SYMBOL_NAME (sym) = VT (objfile) + dn_bufp->ddocfunc.alias;
+ set_name = VT (objfile) + dn_bufp->ddocfunc.alias;
else
- DEPRECATED_SYMBOL_NAME (sym) = VT (objfile) + dn_bufp->ddocfunc.name;
+ set_name = VT (objfile) + dn_bufp->ddocfunc.name;
/* Special hack to get around HP compilers' insistence on
* reporting "main" as "_MAIN_" for C/C++ */
if ((strcmp (DEPRECATED_SYMBOL_NAME (sym), "_MAIN_") == 0) &&
(strcmp (VT (objfile) + dn_bufp->ddocfunc.name, "main") == 0))
- DEPRECATED_SYMBOL_NAME (sym) = VT (objfile) + dn_bufp->ddocfunc.name;
+ set_name = VT (objfile) + dn_bufp->ddocfunc.name;
+ SYMBOL_SET_NAMES (sym, set_name, strlen (set_name), objfile);
+#if 0
+ /* NOTE drow/2004-02-08: The following code is terribly bogus. The
+ demangler should be fixed instead. */
if (dn_bufp->ddocfunc.language == HP_LANGUAGE_CPLUSPLUS)
{
-
- /* SYMBOL_INIT_DEMANGLED_NAME is a macro which winds up
- * calling the demangler in libiberty (cplus_demangle()) to
- * do the job. This generally does the job, even though
- * it's intended for the GNU compiler and not the aCC compiler
- * Note that SYMBOL_INIT_DEMANGLED_NAME calls the
- * demangler with arguments DMGL_PARAMS | DMGL_ANSI.
- * Generally, we don't want params when we display
- * a demangled name, but when I took out the DMGL_PARAMS,
- * some things broke, so I'm leaving it in here, and
- * working around the issue in stack.c. - RT
- */
- SYMBOL_INIT_DEMANGLED_NAME (sym, &objfile->objfile_obstack);
-
- if ((DEPRECATED_SYMBOL_NAME (sym) == VT (objfile) + dn_bufp->ddocfunc.alias) &&
- (!SYMBOL_CPLUS_DEMANGLED_NAME (sym)))
+ if (set_name == VT (objfile) + dn_bufp->ddocfunc.alias
+ && !SYMBOL_CPLUS_DEMANGLED_NAME (sym))
{
-
/* Well, the symbol name is mangled, but the
* demangler in libiberty failed so the demangled
* field is still NULL. Try to
@@ -5451,6 +5428,7 @@ hpread_process_one_debug_symbol (union d
}
}
}
+#endif
/* Add the function symbol to the list of symbols in this blockvector */
if (dn_bufp->ddocfunc.global)
next prev parent reply other threads:[~2004-02-16 21:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-16 21:21 Daniel Jacobowitz
2004-02-16 21:27 ` Daniel Jacobowitz [this message]
2004-02-16 21:40 Michael Elizabeth Chastain
2004-02-16 21:51 ` Elena Zannoni
2004-02-16 22:04 Michael Elizabeth Chastain
2004-02-16 22:11 ` Elena Zannoni
2004-02-17 1:35 Michael Elizabeth Chastain
2004-02-17 1:42 ` Daniel Jacobowitz
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=20040216212741.GA17493@nevyn.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=mec.gnu@mindspring.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