This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ nested classes, namespaces, structs, and compound statements



Daniel Jacobowitz <drow@mvista.com> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]