From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11018 invoked by alias); 20 Jan 2004 15:01:15 -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 11011 invoked from network); 20 Jan 2004 15:01:14 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 20 Jan 2004 15:01:14 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AixNH-0000LV-WE; Tue, 20 Jan 2004 10:01:03 -0500 Date: Tue, 20 Jan 2004 15:01:00 -0000 From: Daniel Jacobowitz To: Paul Hilfinger Cc: carlton@kealia.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] Proposed changes in symbol-handling for Ada Message-ID: <20040120150101.GB10459@nevyn.them.org> Mail-Followup-To: Paul Hilfinger , carlton@kealia.com, gdb-patches@sources.redhat.com References: <200311082255.hA8MtJK08216@otisco.McKusick.COM> <20040120101613.F2871F2945@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040120101613.F2871F2945@nile.gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00556.txt.bz2 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