From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25476 invoked by alias); 10 Apr 2002 19:53:52 -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 25380 invoked from network); 10 Apr 2002 19:53:50 -0000 Received: from unknown (HELO tetsuo.nj.caldera.com) (63.124.204.226) by sources.redhat.com with SMTP; 10 Apr 2002 19:53:50 -0000 Received: from caldera.com (localhost.localdomain [127.0.0.1]) by tetsuo.nj.caldera.com (8.11.6/8.11.6) with ESMTP id g3AK1l902202; Wed, 10 Apr 2002 16:01:47 -0400 Message-ID: <3CB49A25.191E5D27@caldera.com> Date: Wed, 10 Apr 2002 12:53:00 -0000 From: Petr Sorfa Organization: Caldera X-Accept-Language: en MIME-Version: 1.0 To: Daniel Berlin CC: Jim Blandy , gdb@sources.redhat.com, Benjamin Kosnik , Daniel Berlin Subject: Re: C++ nested classes, namespaces, structs, and compound statements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00159.txt.bz2 Hi Daniel, > > Petr Sorfa 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