------- 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
