This is the mail archive of the
mailing list for the GDB project.
Re: C++ nested classes, namespaces, structs, and compound statements
- From: Petr Sorfa <petrs at caldera dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Jim Blandy <jimb at redhat dot com>, gdb at sources dot redhat dot com, Benjamin Kosnik <bkoz at redhat dot com>, Daniel Berlin <dan at dberlin dot org>
- Date: Wed, 10 Apr 2002 16:01:41 -0400
- Subject: Re: C++ nested classes, namespaces, structs, and compound statements
- Organization: Caldera
- References: <Pine.LNX.firstname.lastname@example.org>
> > Petr Sorfa <email@example.com> writes:
> > > I've implemented FORTRAN95 MODULE support which is essentially
> > > equivalent to namespaces (except you cannot have nested MODULEs.) I
> > > treat it internally as a static class. For scoping issues I simply add
> > > (in DWARF) the current local symbols to the MODULE to the local symbols
> > > of the PROGRAM, CONTAINS, SUBROUTINE and FUNCTION scopes. A similar kind
> > > of approach will allow nested C++ namespaces (flame bait comment.)
> > I'm not sure I understand your implementation. (And I'm sure I don't
> > understand FORTRAN...) So, when some program construct imports a
> > module, you actually repeat the declarations for the imported module's
> > contents in the debug info for the importing construct?
> And if so, isn't the memory usage absurd for large programs?
No. The compiler generates a DW_TAG_imported_declaration for module
contents which basically consists of DW_AT_import attributes that
provide dwarf refs to the actual module contents (and internal
structure.) I've extended support for these tags and attributes. It also
provides support for DW_AT_ref_addr outside of the current compilation
unit with external modules.
I guess I didn't explain it too well, it really adds the scope of the
module (as defined by DW_TAG_imported_declaration) to the current scope
hierarchy (rather than recreating the information as my initial