From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27190 invoked by alias); 6 Sep 2002 19:55:03 -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 27183 invoked from network); 6 Sep 2002 19:55:03 -0000 Received: from unknown (HELO mail.cdt.org) (206.112.85.61) by sources.redhat.com with SMTP; 6 Sep 2002 19:55:03 -0000 Received: from www.dberlin.org (pool-151-200-239-242.res.east.verizon.net [151.200.239.242]) by mail.cdt.org (Postfix) with ESMTP id DD3AD49003F; Fri, 6 Sep 2002 15:33:24 -0400 (EDT) Received: by www.dberlin.org (Postfix, from userid 503) id B9C331851427; Fri, 6 Sep 2002 15:55:00 -0400 (EDT) Received: from dberlin2.local. (unknown [192.168.0.252]) by www.dberlin.org (Postfix) with ESMTP id 33FA81850002; Fri, 6 Sep 2002 15:55:00 -0400 (EDT) Date: Fri, 06 Sep 2002 12:55:00 -0000 Subject: Re: struct environment Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: David Carlton , gdb To: Daniel Jacobowitz From: Daniel Berlin In-Reply-To: <20020906194110.GA12820@nevyn.them.org> Message-Id: <8683BB1E-C1D2-11D6-AB8C-000393575BCC@dberlin.org> Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_APPLEMAIL version=2.40-cvs X-Spam-Level: X-SW-Source: 2002-09/txt/msg00038.txt.bz2 On Friday, September 6, 2002, at 03:41 PM, Daniel Jacobowitz wrote: > 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? I've been too busy with law school and interviews (2nd year law students have interviews for summer jobs in late august and early september. Absurd, no?) to work on it. I did make sure Peter Sofa and Jim Blandy know this, and that if they want it done anytime soon, to work on it themselves. The changes Jim requested probably wouldn't take more than a day or two to implement, i just don't have that day or two right now. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer >