From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26506 invoked by alias); 8 Nov 2003 21:31:19 -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 26492 invoked from network); 8 Nov 2003 21:31:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 8 Nov 2003 21:31:19 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AIafu-0007o3-Dx for ; Sat, 08 Nov 2003 16:31:18 -0500 Date: Sat, 08 Nov 2003 21:31:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [rfa:symtab] SYMBOL_LOCATION_FUNCS -> SYMBOL_OPS Message-ID: <20031108213118.GA29731@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <3FAD53AD.4030003@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FAD53AD.4030003@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00155.txt.bz2 On Sat, Nov 08, 2003 at 03:35:57PM -0500, Andrew Cagney wrote: > Hello, > > This patch generalizes the per-symbol location_funcs, replacing them > with a symbol_ops vector (the contents are unchanged). The patch > doesn't change the size of the symbol. > > As the comment hints: > > + /* NOTE: cagney/2003-11-02: The fields "aclass" and "ops" contain > + overlaping information. Since GDB has only a small finite number > + of symbol classes it should be possible to merge the two fields > + into a single ops-table "index". Each entry providing both the > + "ops" and the "aclass" values. Doing that would shave 32 bits > + off every symbol. */ > > The patch sets us up for a more significant change - merge "ops" and > "aclass" - and hence eliminates 32 bits (or 20%) of each symbol. I > should note that right now the details of the merge are "left as an > exercise for the reader". FWIW, this patch looks good to me. I only have two questions. One is with the generalized name - do you expect anything besides the location (the aclass really is a part of the location, I think) to be handled by these ops? I'm not sure what else there is, so it's just an idle thought. And, I think I see where you're going with the index idea, but since it wasn't obvious until the second time through: the index could take up to ten bits, replacing the address class, and thereby eliminating the ops pointer. That's where the 32 bits comes from, not from eliminating aclass. This costs a table lookup every time you want to get at the aclass or ops, but that's probably OK. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer