From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7767 invoked by alias); 17 Sep 2002 16:07:10 -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 7757 invoked from network); 17 Sep 2002 16:07:09 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 17 Sep 2002 16:07:09 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17rLoR-0003zk-00; Tue, 17 Sep 2002 12:07:00 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17rKsO-0005NV-00; Tue, 17 Sep 2002 12:07:00 -0400 Date: Tue, 17 Sep 2002 09:07:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: David Carlton , gdb Subject: Re: struct environment Message-ID: <20020917160700.GA20451@nevyn.them.org> Mail-Followup-To: Andrew Cagney , David Carlton , gdb References: <3D86DE18.6030003@ges.redhat.com> <20020917134057.GA26237@nevyn.them.org> <3D875149.9080502@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D875149.9080502@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00223.txt.bz2 On Tue, Sep 17, 2002 at 11:59:05AM -0400, Andrew Cagney wrote: > >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? Not sure what you mean. I don't see any problem with the way David described it - a dictionary which could be ordered (list) or unordered (hash) depending on the context. I wouldn't call that overengineered. > >>- 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. This is legal C++: namespace D {} namespace C { using namespace D; int x, y; } namespace D { using namespace C; int x, z; } If using just grew a nametab we'd get into a great deal of trouble. > >>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)? search_symbols? The plan is not to stop with blocks; the point is to use the same interface for the global symbol tables also. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer