From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5610 invoked by alias); 18 Dec 2003 02:22:35 -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 5603 invoked from network); 18 Dec 2003 02:22:34 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 18 Dec 2003 02:22:34 -0000 Received: by zenia.home (Postfix, from userid 5433) id 211C2207A3; Wed, 17 Dec 2003 21:19:16 -0500 (EST) To: Daniel Jacobowitz Cc: David Carlton , gdb Subject: Re: new demangler References: <20031215225452.GA23169@nevyn.them.org> <20031216053022.GA28127@nevyn.them.org> From: Jim Blandy Date: Thu, 18 Dec 2003 02:22:00 -0000 In-Reply-To: <20031216053022.GA28127@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-12/txt/msg00245.txt.bz2 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 think the trees would be a lot easier to do certain kinds of matching on, too. "Is this a user-defined cast operator?"