From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18825 invoked by alias); 17 Sep 2002 19:16:54 -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 18813 invoked from network); 17 Sep 2002 19:16:52 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 17 Sep 2002 19:16:52 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C0FA33DAA; Tue, 17 Sep 2002 15:16:52 -0400 (EDT) Message-ID: <3D877FA4.8050607@ges.redhat.com> Date: Tue, 17 Sep 2002 12:16:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Carlton Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] convert blocks to dictionaries, phase 1, main part References: <3D87587B.9080304@ges.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00349.txt.bz2 >> - 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. Yep. If you think accessor macro's are a good idea, try debugging / using sim/common some time :-( Also grep -e '->hashtable' works pretty well. > 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. Have a look at more recent code such as regcache.h. > ALL_DICT_SYMBOLS; but I'm happy to get rid of that since the interface > 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. The ALL_xxx_yyy() iterator can probably stay. Its an ``accepted'' convention. > 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. Yes, please. Symbolic constants as enum's is recommended. >> - 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. Then just mention those that do apply. (I thought DanielJ indicated that you just doing an initial linear implementation?) >> - 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? target's not hosts :-) There is some sed in MAINTAINERS for generating the target list. Richard E, I believe, posted a script for doing all the config's and builds. Andrew