This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa] teach lookup_symbol about namespace scope


On Fri, 16 May 2003 10:53:34 -0400 , Paul Hilfinger <hilfingr@gnat.com> said:

> 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.

Changes over the last half-year might make things worse for you folks,
but they might not; probably there's no point worrying about it in
advance until concrete problems start to arise.  Daniel's changes
earlier this year help with the costs of demangling, but they aren't
going to vanish.

> 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.

We could probably use this feature in the non-Ada case, too, to get
C++ right...

> 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>.  

I'm curious: how frequent is this optional suffix?  Because this looks
so simple that it seems like the time costs for demangling would be
very small: all you have to do is skip "prefix__" and then check for
the optional suffix (which I assume is easy to recognize?), and it
seems to me that other costs in building symbol information would
swamp that.  And we could design a scheme where, if the suffix was
absent, the mangled and demangled names would share memory, since the
demangled name is a final substring of the mangled name.  So if that's
the common case, then the memory cost would go away as well.  We'd
have to tinker with symbol_set_names a bit, but that's okay: there's
already a somewhat gross Java hack in there, and having to
special-case Ada as well would give us an excuse to clean it up.

> 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.

Do Ada symbols have both the demangled and linkage name set?  Because
if you're never setting the demangled name, I would think that you
wouldn't have to use a special macro in the Ada case.  (By the way, we
used to have a different macro called SYMBOL_SEARCH_NAME, but that's a
separate issue.)

> 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.

Sounds great.

David Carlton
carlton@math.stanford.edu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]