Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Paul Hilfinger <hilfingr@gnat.com>
Cc: carlton@kealia.com, gdb-patches@sources.redhat.com
Subject: Re: [RFC] Proposed changes in symbol-handling for Ada
Date: Tue, 20 Jan 2004 15:01:00 -0000	[thread overview]
Message-ID: <20040120150101.GB10459@nevyn.them.org> (raw)
In-Reply-To: <20040120101613.F2871F2945@nile.gnat.com>

On Tue, Jan 20, 2004 at 05:16:13AM -0500, Paul Hilfinger wrote:
> 
> 
> David,
> 
> I'd appreciate your comments on the following approach to handling the
> ... um ... difference of opinion between the Ada world and everyone else
> regarding symbols.  We've briefly discussed it before; now I'd like to get
> specific.
> 
> We decided years ago NOT to store demangled names, considering it an
> unnecessary waste of space (some ACT customers have very large symbol tables)
> and start-up time.  Instead we MANGLE names that are searched for and then
> look those up.  In our own sources, we've added a level of indirection to
> minimize the effect on the rest of GDB.  It's worked out well, and we've 
> experienced very few maintenance problems with this approach (aside, 
> of course, from a SMALL amount of fuss to adapt your major re-organization
> of the symbol stuff (:->)).  
> 
> Basically, we found it sufficient to introduce some additional macros in 
> symtab.h: 
> 
> +/* Macro that returns the name to be used when sorting and searching symbols. 
> +   In  C++, Chill, and Java, we search for the demangled form of a name,
> +   and so sort symbols accordingly.  In Ada, however, we search by mangled
> +   name. */
> +#define SYMBOL_SEARCH_NAME(symbol)					 \
> +   (SYMBOL_LANGUAGE (symbol) == language_ada 				 \
> +    ? SYMBOL_LINKAGE_NAME (symbol)					 \
> +    : SYMBOL_NATURAL_NAME (symbol))

Hi Paul,

I'd like to get your opinions on another change I've been considering,
first.  It may turn out to be completely unsuitable for Ada, better to
know now than later :)

Rather than demangling at startup, we ask each mangled name for a base
identifier.  This can be done reasonably efficiently - I hope - I
haven't performed measurements yet.  Then, when we search for a symbol,
we wildcard for the basename.  We demangle everything with that
basename.  If you do a search that doesn't know the basename you
have to un-lazy all symbols, of course, but I don't think that's much
of a change.

This would provide, from my undersanding, a small simplification versus
the Ada approach and a solid speedup for the non-Ada approach.

Does Ada have:
 - the concept of a "basename" for each mangled name
     For C++, this would be foo::bar::baz() -> baz, and the basename is
     always stored within the mangled name so can be represented as an
     offset and length.  For Java, I think this is true except for
     escape sequences.  I believe there are fixed rules about what
     characters get escaped, so we can do that to symbols we search for
     before looking for the basename.
 - Reasonably unique (i.e. user-choosable) basenames.  If every package
   (or whatever they are in ada) has a method with the same basename,
   then this scheme obviously won't work.
 - Any other problems?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2004-01-20 15:01 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 [this message]
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
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=20040120150101.GB10459@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=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