From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23363 invoked by alias); 16 Apr 2002 21:52:07 -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 23349 invoked from network); 16 Apr 2002 21:52:02 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 16 Apr 2002 21:52:02 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 654785EA12; Tue, 16 Apr 2002 16:46:27 -0500 (EST) To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: C++ nested classes, namespaces, structs, and compound statements References: <20020406044204.245E45EA11@zwingli.cygnus.com> <20020406013408.A4570@nevyn.them.org> <20020408214935.A14098@nevyn.them.org> <20020410150824.A22581@nevyn.them.org> <20020412195613.C11562@nevyn.them.org> From: Jim Blandy Date: Tue, 16 Apr 2002 14:52:00 -0000 In-Reply-To: <20020412195613.C11562@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00274.txt.bz2 Daniel Jacobowitz writes: > > Okay, I think I see. You're preserving the distinctions implicit in > > the existing structures (fields and symbols are separate), > > distinguishing types from symbols (i.e. an entry for a typedef would > > be an environment_entry whose kind == type_kind, instead of a symbol > > with an address class of LOC_TYPEDEF), and positing that namespaces > > would be a fourth kind of thing. The `data' field would point to a > > `struct type' or a `struct field', or whatever. > > Yes, that's right. There's also transparent scopes (which might be a > special kind of namespace... or not). By that I mean {} enclosed > regions with their own local variables. A function belongs to a > namespace, a namespace does not enclose a particular range of PCs - but > a scope does enclose a particular PC range. Hopefully but not > necessarily a single contiguous range. Optimization or explicit > .section directives could break it up. At the moment GDB assumes they're contiguous. (Of course.) Dwarf 3 allows one to describe lexical blocks that occupy discontinuous address ranges, but we don't read that. (Of course.) But why would lexical blocks occur in an environment? They don't generally have names. Functions do, but I would say a function "has a" lexical block, rather than saying it "is a" lexical block.