From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29284 invoked by alias); 19 May 2003 16:35:37 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29271 invoked from network); 19 May 2003 16:35:37 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 19 May 2003 16:35:37 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h4JGZSa26137; Mon, 19 May 2003 09:35:28 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Paul Hilfinger Cc: ezannoni@redhat.com, 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 References: <20030519095521.38880F2D9E@nile.gnat.com> From: David Carlton Date: Mon, 19 May 2003 16:35:00 -0000 In-Reply-To: <20030519095521.38880F2D9E@nile.gnat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00338.txt.bz2 On Fri, 16 May 2003 10:53:34 -0400 , Paul Hilfinger 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 > __ > and we need to be able to match this name given either > either __ or . 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