From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3100 invoked by alias); 18 Dec 2003 05:21:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3090 invoked from network); 18 Dec 2003 05:21:29 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 18 Dec 2003 05:21:29 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AWqbD-0003ue-GU; Thu, 18 Dec 2003 00:21:23 -0500 Date: Thu, 18 Dec 2003 05:21:00 -0000 From: Daniel Jacobowitz To: Ian Lance Taylor Cc: Jim Blandy , David Carlton , gdb Subject: Re: new demangler Message-ID: <20031218052122.GA7319@nevyn.them.org> Mail-Followup-To: Ian Lance Taylor , Jim Blandy , David Carlton , gdb References: <20031216053022.GA28127@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00248.txt.bz2 On Wed, Dec 17, 2003 at 09:58:29PM -0500, Ian Lance Taylor wrote: > Jim Blandy writes: > > > Daniel Jacobowitz writes: > > > When I can figure out a few more points of C++ grammar - it's taken me > > > a *(!&#@ month so far and it's barely functional... - I'll have an > > > efficient solution for breaking down names into the demangler's trees. > > > This will let us get the information we want much more reliably. > > > > When working on big C++ programs, I think I remember seeing that the > > mangled and demangled names take up a *lot* of memory. > > > > If that recollection is correct, it might be cool to have GDB store > > the trees instead of the names, and throw a bcache at the nodes in > > these demangled name trees, working from the leaves upward, to get > > maximum sharing. I bet that would bring the memory requirements down > > to something more closely resembling the actual number of classes, > > methods, etc. in the program. I don't know how well it would work compared to simply cutting down on the number of demangled names we need in memory. Specifically, instead of one symbol table with fully qualified names, lots of little dictionaries with the names of members. > > I think the trees would be a lot easier to do certain kinds of > > matching on, too. "Is this a user-defined cast operator?" > > Tangentially, note that the trees that I wrote for the demangler are > based pretty directly on the mangling ABI. They just follow the > grammar productions used there. > > To use them for anything other than demangling, it might be useful to > try to work out a good tree representation for C++ names. Then I or > somebody can modify the demangler to use that tree representation > instead. It would probably be pretty close to the trees I use, but I > doubt it would be identical. So far, simply using yours hasn't been a problem. A few of my rules are a little awkward, but compared to the hacks normally found in yacc grammars it's a downright beauty. Was anything ever decided about conversion operators and typeof()? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer