From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31050 invoked by alias); 17 Sep 2002 18:04:00 -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 31026 invoked from network); 17 Sep 2002 18:03:59 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 17 Sep 2002 18:03:59 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g8HI3vJ12295; Tue, 17 Sep 2002 11:03:57 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] convert blocks to dictionaries, phase 1, main part References: <3D87587B.9080304@ges.redhat.com> From: David Carlton Date: Tue, 17 Sep 2002 11:04:00 -0000 In-Reply-To: <3D87587B.9080304@ges.redhat.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: 2002-09/txt/msg00346.txt.bz2 On Tue, 17 Sep 2002 12:29:47 -0400, Andrew Cagney said: > - create a header ``dictionary.h'' / ``nametab.h'' / ... that defines > the interfaces for this new object. Sure. > - macro's are bad m'kay :-) Even accessor macros for members of structures? Gee, I like those: it's a lot easier to find all places where, say, struct block's 'hashtable' member is being used by grepping for 'BLOCK_HASHTABLE' than by grepping for 'hashtable' and then sorting out which ones of those really are referring to the 'hashtable' member as opposed to some other use of the phrase. Admittedly, that's less important here since the structures in question are opaque, so they'll only be accessed within one file. So if you want me to move away from them, that's fine; I was just trying to follow existing practice in symtab.h and gdbtypes.h. The macros that are currently used (as seen in , modulo replacing 'environment' by 'dictionary', not just in the smaller portion of it that I recently put up for RFA) fit (I think!) into the following taxonomy: * One-argument accessor macros for members of structures. * Two-argument accessor macros for members of structures that are arrays: these accessor macros take the index into the array as a second argument. * Symbolic constants. * ALL_DICT_SYMBOLS, to make looping over all the symbols easier. I think the only macro that is publically accessible is ALL_DICT_SYMBOLS; but I'm happy to get rid of that since the interface to iterating over symbols in dictionaries is a lot easier than the interface to iterating over symbols in blocks. So if you want me to get rid of all macros (other than, presumably, symbolic constants, though I could use the enum trick there), I can certainly do that. > - just implement interfaces sufficient for the immediate needs. For > instance, instead of providing ``enum dict_type'', just describe > the idea. Since we can compile with -Werror, changing internal > interface, when there is evidence that it is actually needed, has > become relativly easy. dict_type really is necessary currently: I need to provide hash tables and linear environments to support the existing functionality of blocks. It's just like the 'hashtable' member of struct block. > - keep gdbint.texinfo in mind Right. > - you'll want to start compiling all targets Sure. How do I go about doing this? I don't have access to a wide range of machines; are there machines at Red Hat that I can use? David Carlton carlton@math.stanford.edu