From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2267 invoked by alias); 17 Sep 2002 15:59:12 -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 2259 invoked from network); 17 Sep 2002 15:59:10 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 17 Sep 2002 15:59:10 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0EFCB3DAA; Tue, 17 Sep 2002 11:59:06 -0400 (EDT) Message-ID: <3D875149.9080502@ges.redhat.com> Date: Tue, 17 Sep 2002 08:59: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: Daniel Jacobowitz Cc: David Carlton , gdb Subject: Re: struct environment References: <3D86DE18.6030003@ges.redhat.com> <20020917134057.GA26237@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00222.txt.bz2 > On Tue, Sep 17, 2002 at 03:47:36AM -0400, Andrew Cagney wrote: > >> Btw, try ``struct nametab''? These are just tables for mapping a name >> onto a symbol? > > > Hmm.. > > >> Having also gone over the original thread, two things come to mind: >> >> - what effect will this have on GDB's foot print? The original proposal >> was to put these things everwhere (structs, unions, ...). I don't think >> that is necessary and would cause serious bloat. Instead, initially, I >> think these tables could be simple linear lists (that is what ``struct >> block'' currently implements so it can't be any worse :-) (just the >> global / final table is special :-). > > > Why do you think this will cause any bloat? This is why David > suggested a model of block with a linear list implementation. That is good news, the early discussion was describing a totally generic implementation being applied to everything. Can I assume that no one has immediate plans for adding this to the type system? >> - Am I correct to think that the objective is to create a directed >> acyclic graph of nametabs and have lookups search through each in turn. > > > Well, sort of. It won't be a DAG necessarily (I think that mutual > "using" statements are legal in C++; I remember a GCC bug involving > them was fixed not long ago), and it will be somewhat complicated > figuring out which ones to look up (namespace links are different than > block scope links). Don't forget that GDB doesn't need to model the language. Just the namespace behavior at a given PC. The effect of "using" would be to just grow a nametab in someway. >> In terms of operations, I would concentrate on determing exactly GDB >> needs (rather than you think it needs) GDB is 15 years old so chance >> has it the operations have been identified already. I know of two >> operations off hand: >> print foo >> which gets turned into struct symbol *lookup("foo",``block'') and, >> print foo >> which turns into ``const char **tabexpand("foo", ``block'')''. Any others? > > > At least iterate over all, search regexp. Yes (iterate over would come from things like ``info locals''). Regex (I know it's used somewhere)? Andrew