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


Hi Daniel,

> > Petr Sorfa <petrs@caldera.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
statement implies.)

Petr


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