From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13771 invoked by alias); 15 Aug 2008 18:30:51 -0000 Received: (qmail 13021 invoked by uid 48); 15 Aug 2008 18:29:29 -0000 Date: Fri, 15 Aug 2008 18:30:00 -0000 Message-ID: <20080815182929.13020.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/29635] debug info of modules In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg01124.txt.bz2 ------- Comment #5 from jakub at gcc dot gnu dot org 2008-08-15 18:29 ------- Created an attachment (id=16077) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16077&action=view) gcc44-pr29635.patch Initial patch, which generates DW_TAG_module in the compilation unit that defines the module and puts all module procedures, variables, DW_TAG_common_blocks and derived types as children of that DIE. ATM it uses the same weird double DIE way as C++ namespaces use (one DIE in DW_TAG_namespace (resp. DW_TAG_module in Fortran) with DW_AT_declaration 1 and another outside of the namespace/module with DW_AT_specification. Any ideas why does C++ do this? To emit proper DW_TAG_imported_{declaration,module} DIEs there is much more work. One problem is that Fortran FE rereads the *.mod each time a USE statement is seen, so finding the same NAMESPACE_DECL is harder (we'd need to add some data structure mapping a module name to the NAMESPACE_DECL). If we have that, for non-renaming USE or USE, ONLY it is easy (at least in the same CU as the module definition), but for renaming we'd need to extend the API of the imported_module_or_decl debug_hook. The USE modx, a=>b, c=>d renaming also needs the DW_TAG_imported_declaration's with the renamings to be children of DW_TAG_imported_module. I think the renaming is visible from the symtree (the renamed name is in symtree->name, original in symtree->n.sym->name). Another problem are USE statements in different compilation unit from the one that defines the module. We probably can't output a reference to DW_TAG_module from a different .o file, so we'd need to emit DW_TAG_module in that case too, but can we just put into it just the module variables, procedures etc. that are used in the CU? I'm afraid module loading throws away stuff that is not needed. -- jakub at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|steven at gcc dot gnu dot |jakub at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29635