From: David Carlton <carlton@kealia.com>
To: Paul Hilfinger <hilfingr@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Proposed changes in symbol-handling for Ada
Date: Tue, 20 Jan 2004 23:05:00 -0000 [thread overview]
Message-ID: <yf2hdyqfcgm.fsf@hawaii.kealia.com> (raw)
In-Reply-To: <20040120101613.F2871F2945@nile.gnat.com> (Paul Hilfinger's message of "Tue, 20 Jan 2004 05:16:13 -0500 (EST)")
On Tue, 20 Jan 2004 05:16:13 -0500 (EST), Paul Hilfinger <hilfingr@gnat.com> said:
> Basically, we found it sufficient to introduce some additional macros in
> symtab.h:
> +#define SYMBOL_SEARCH_NAME(symbol) \
> +#define SYMBOL_MATCHES_SEARCH_NAME(symbol, name) \
> +#define SYMBOL_DEMANGLED_SEARCH_NAME(symbol) \
These don't seem unreasonable to me, given your desires. If I were a
symtab maintainer, I would ask for measurements to see how much
time/memory doing things your way saves you, but I'm willing to
imagine that it really does help you. Given that, my main worry is:
> + else if (gsymbol->language == language_ada)
> + {
> + return ada_demangle (gsymbol->name);
> + }
It used to be the case that the return value of
SYMBOL_{NATURAL,DEMANGLED,PRINT}_NAME had a lifetime that always
lasted as long as the symbol in question; your proposal would mean
that that would no longer be true. And changing that assumption makes
me nervous.
I'm not sure what to do about that. Choices that come to mind are:
1) Have the SYMBOL_DEMANGLED_NAME of Ada symbols always be NULL, and
the SYMBOL_NATURAL_NAME be the mangled name. In which case, there's
no need for the search name stuff, but it makes it harder for Ada
code to use, say, output code in other portions of GDB.
2) Not allow callers to assume that the output of SYMBOL_NATURAL_NAME
and friends lasts for very long. Which is a fragile assumption to
make, and violations of it will be hard to find.
3) Have Ada symbols save the demangled names of symbols after being
forced to demangle them. This could cause a memory increase if you
for some reason have to demangle lots of names.
I think I would vote for option 3 - after all, one point of your
proposal is that you _don't_ have to demangle lots of names. And, if
you did have to do that once for some reason, then probably there's a
good chance that you'd have to do it a second time, at which point
caching becomes a time win, if not a space win.
(Hmm: where would you allocate the cached name from? You can't get at
the appropriate obstack from the symbol, can you? Sigh. I do not
enjoy worrying about memory management when programming in C.)
David Carlton
carlton@kealia.com
next prev parent reply other threads:[~2004-01-20 23:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-08 22:55 Interactions of symbol-lookup with language Paul N. Hilfinger
2003-11-10 17:07 ` David Carlton
2004-01-20 10:16 ` [RFC] Proposed changes in symbol-handling for Ada Paul Hilfinger
2004-01-20 15:01 ` Daniel Jacobowitz
2004-01-21 10:55 ` Paul Hilfinger
2004-01-21 15:19 ` Daniel Jacobowitz
2004-01-23 21:08 ` Andrew Cagney
2004-01-20 23:05 ` David Carlton [this message]
2004-01-21 11:22 ` Paul Hilfinger
2004-01-21 16:49 ` David Carlton
2004-01-21 18:50 ` Daniel Jacobowitz
2003-11-11 1:23 ` Interactions of symbol-lookup with language Elena Zannoni
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=yf2hdyqfcgm.fsf@hawaii.kealia.com \
--to=carlton@kealia.com \
--cc=gdb-patches@sources.redhat.com \
--cc=hilfingr@gnat.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