From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11793 invoked by alias); 29 Apr 2003 19:16:50 -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 11779 invoked from network); 29 Apr 2003 19:16:49 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 29 Apr 2003 19:16:49 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h3TJGgj24229; Tue, 29 Apr 2003 12:16:42 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb , Elena Zannoni , Jim Blandy Subject: Re: [rfc] struct dictionary References: <3EA89AB3.6050403@redhat.com> <3EAE95CD.8070207@redhat.com> From: David Carlton Date: Tue, 29 Apr 2003 19:16:00 -0000 In-Reply-To: <3EAE95CD.8070207@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: 2003-04/txt/msg00333.txt.bz2 On Tue, 29 Apr 2003 11:10:05 -0400, Andrew Cagney said: >> On Fri, 25 Apr 2003 11:31:35 -0400, Andrew Cagney said: >> >>> Ok, humor me ... >>> http://sources.redhat.com/ml/gdb/2003-04/msg00017.html why even >>> build these data structures during symbol reading? It takes time >>> and space, yet is probably never used. Why not on-demand build this >>> dictionary specialized for the block? >> That sounds great to me if we can get it to work. It's certainly >> another reason to try to get the symbol lookup stuff abstracted behind >> an opaque interface: it makes lazy loading of data a lot easier. > But which interface? > A block has a language, and [I think] it's the language that, in the > end decides that block's name->symbol lookup strategy. The language > can, on demand, build a dictionary for its block. Currently, all uses of symbols in blocks either iterate over all symbols or else are looking for symbols with a given natural name. As you say, because of the features of certain languages, sometimes you need to refine the search further beyond that, but that's a good first cut. So having iterators dict_iterator_{first,next} and dict_iter_name_{first,next} is a good first step: it unifies all the existing mechanisms for symbol lookup, but doesn't commit to any sort of implementation mechanism. It certainly would allow for constructing the actual data structures on demand: for example, we could add an implementation that doesn't actually build the data structures storing the symbols until the first time that an iterator is called. I'm certainly willing to believe that the interface might change in the future; but separating the interface from the implementation is a good first step no matter what. I kind of get the impression that I'm missing your point somehow and that we're talking past each other. I'll post a concrete patch soon (Wednesday, maybe? It's done on my laptop, but I don't have my laptop with me), and hopefully that will clarify matters. David Carlton carlton@math.stanford.edu