From: Paul Hilfinger <hilfingr@gnat.com>
To: ezannoni@redhat.com, carlton@math.stanford.edu,
Cc: drow@mvista.com, cagney@redhat.com,
gdb-patches@sources.redhat.com, jimb@redhat.com,
brobecker@gnat.com
Subject: Re: [rfa] teach lookup_symbol about namespace scope
Date: Mon, 19 May 2003 09:55:00 -0000 [thread overview]
Message-ID: <20030519095521.38880F2D9E@nile.gnat.com> (raw)
Yes, Ada does do things weirdly at the moment, and will probably continue
to do so, but I don't think this need worry anybody. Our particular needs
are:
1. We do NOT cache demangled names, and we look up all symbols using
mangled names. Originally, we just followed C++, but changed when
we discovered that our customers had HUGE executables for which the
startup and memory costs became substantial. David Carlton expressed
concern that our approach must cause maintenance problems, but to date
(i.e., since early 1998), the approach has caused no problems for us.
2. We generally expect multiple symbol matches, rather than just taking
the first match, and therefore our main lookup routine returns a list
of symbols.
3. Linkage (mangled) names have the form
<prefix>__<simple name><optional suffic>
and we need to be able to match this name given either
either <prefix>__<simple name> or <simple name>.
In our sources, I have introduced a macro SYMBOL_SEARCH_NAME that in
the Ada case is equivalent to SYMBOL_LINKAGE_NAME and in other cases
to the demangled name. As long as symbol tables (hash tables, etc.)
are built and searched according to the search name, everything just
works. To handle the need for a symbol list (as Elena mentions) we
simply wrote our own lookup_symbol. We'll certainly take advantage of
any opportunity to dump the latter code, of course, and will
contribute little hooks if that's what it takes. However, it wasn't
difficult to create our version in the first place and it has not been
hard to maintain, so even in the worst case (i.e., we have to rewrite
symbol lookup entirely) it will not be a terrible problem. Besides, I
am confident that with the spiffy new design we're seeing, adaptation
for Ada should be even easier than before.
Paul Hilfinger
next reply other threads:[~2003-05-19 9:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-19 9:55 Paul Hilfinger [this message]
2003-05-19 16:35 ` David Carlton
2003-05-20 11:10 ` Paul Hilfinger
2003-05-20 16:17 ` David Carlton
-- strict thread matches above, loose matches on Subject: below --
2003-04-24 14:34 David Carlton
2003-04-24 20:14 ` Eli Zaretskii
2003-04-24 20:18 ` Daniel Jacobowitz
2003-04-24 20:44 ` David Carlton
2003-05-16 14:48 ` Elena Zannoni
2003-05-16 17:26 ` David Carlton
2003-05-16 19:49 ` Elena Zannoni
2003-05-16 20:51 ` David Carlton
2003-05-17 0:09 ` Joel Brobecker
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=20030519095521.38880F2D9E@nile.gnat.com \
--to=hilfingr@gnat.com \
--cc=brobecker@gnat.com \
--cc=cagney@redhat.com \
--cc=carlton@math.stanford.edu \
--cc=drow@mvista.com \
--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