From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19153 invoked by alias); 6 Sep 2002 19:41:35 -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 19145 invoked from network); 6 Sep 2002 19:41:34 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 6 Sep 2002 19:41:34 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17nPul-00053W-00; Fri, 06 Sep 2002 15:41:16 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17nOyc-0003Nq-00; Fri, 06 Sep 2002 15:41:10 -0400 Date: Fri, 06 Sep 2002 12:41:00 -0000 From: Daniel Jacobowitz To: Daniel Berlin Cc: David Carlton , gdb Subject: Re: struct environment Message-ID: <20020906194110.GA12820@nevyn.them.org> Mail-Followup-To: Daniel Berlin , David Carlton , gdb References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00037.txt.bz2 On Fri, Sep 06, 2002 at 03:34:34PM -0400, Daniel Berlin wrote: > > > > one which might not even be necessary (see below). > > > > >> And there's another, even more important reason: the global > > >> environment (and, in the future, namespaces). The global > > >> environment spans multiple files, uses lazy evaluation > > >> (i.e. partial_symbols), and there's even minimal_symbols to > > >> shoehorn in there somehow. So it's going to need its own special > > >> implementation (which will be much more complicated than the > > >> implementations for blocks). > > > > > This is why I don't like the environment == list-of-symbols thing. > > > An environment may HAVE a list of symbols, but it is not its list of > > > symbols. You shouldn't grow the list of symbols in the global > > > environment when a new file is added. Instead you should associate > > > a new list of symbols with it. > > This makes lookup dependent on two things, instead of one (number of > files, and number of names, vs number of names). > Bad idea when you can avoid it. > If you want to know what blocks go with which files, than store *that* > information. > Removal is *not* the common case. Well, what I had in mind when I wrote that was the same sort of thing you originally described - with a cached mapping of symbols -> blocks. I do need to sit down and think about how namespaces interact here however... gets a little peculiar. > Note that this wasn't the first time someone wanted to do this. HP has a > whole "FAT_FREE_PSYMTABS" thing in WDB. Yeah. Killing psymtabs in general would be nice but that's tabled behind stub methods (which I am slowing quashing). What's the current status of the location expression stuff, by the way? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer