Re: [RFA] Patch for supportinf DW_TAG_module / FORTRAN modules

[Petr Sorfa <petrs@caldera.com>]

Hi Jim,

> If I understand this patch correctly, it stores a Fortran module in
> GDB's symbol table as if it were a C++ structure type, full of static
> data and function members.  A Fortran module gets stored in GDB's
> symbol table as a LOC_TYPEDEF symbol.  Is that right?
Yes. The reason for a LOC_TYPEDEF is to resolve some evaluation issues.
The module in FORTRAN is not really an instance of anything since
everything is static and there is only one occurance of it (i.e. it is
not really equivalent to a C++ class), but rather a type. I think a
FORTRAN module should rather be thought of as a C++ namespace rather
than a C++ class. In fact this patch puts in ground work for namespace
handling.

> I'd like to hear other folks' opinions on this.
> 
> It seems to me like it would work, since a class establishes a scope
> that behaves very much like a module.  Isn't Class::member, where
> member is a static thingy, very much like Module::member (or whatever
> the Fortran syntax is)?  We already have logic for resolving class
> scopes; I don't immediately see why module scopes need to behave any
> differently.
I thought it did this. Can you point out where I'm going wrong?

> But I think a module should be represented by something that calls
> itself a module, not a typedef.  How will people feel reading a
> comment explaining that a LOC_TYPEDEF for a type with TYPE_CODE_CLASS
> is how we represent Fortran modules?  I'm not sure that counts as good
> maintenance.
I originally introduced a TYPE_CODE_MODULE that was basically equivalent
to a TYPE_CODE_CLASS, as much as TYPE_CODE_CLASS is really
TYPE_CODE_STRUCT. I think I must have pulled it out for the patch. I can
put it back in and make it equivalent to TYPE_CODE_CLASS.

> Perhaps we should introduce LOC_MODULE, or TYPE_CODE_MODULE.
TYPE_CODE_MODULE explained above. However, LOC_MODULE would be
equivalent in this case to LOC_TYPEDEF. If you look at the comment for
LOC_TYPEDEF concerning namespace (below this sentence) I am using a
similar angle.

   /* Value not used; definition in SYMBOL_TYPE.  Symbols in the
namespace
       STRUCT_NAMESPACE all have this class.  */ 

> Or maybe this is okay for now.  When we provide better support for C++
> namespaces, Fortran modules can become a variant of that, which feels
> like a better fit.
Yes. *Cough* maybe this patch can provide support for namespaces? ;o)
 
> But without a better sense of how people feel about this issue,
> I don't think I can comment specifically on this patch.
Ok, one step at a time. One I get your feedback on this, we can start
making a plan on how I should do this.

Petr
> 
> Petr Sorfa <petrs@caldera.com> writes:
> 
> > Hi,
> >
> > The patch below provides support for DW_TAG_module which is used to
> > represent FORTRAN modules, and possibly other language constructs, such
> > as C++ namespaces. The patch basically provides support for a module as
> > a C++ class with static members and functions.
> >
> > 2002-07-16  Petr Sorfa <petrs@caldera.com>
> >
> >         * dwarf2read.c (dwarf2_update_pc_bounds): New function
> >         that updates a die's low and high pc bound. Used to
> >         remedy possible inconsistencies between ELF and DWARF
> >         information.
> >         (dwarf2_get_child_pc_bounds): New function that
> >         calculates the scope bounds of a die's children.
> >         (dwarf2_add_member_fn): Added a new argument that holds
> >         a parent die's tag type. Used to determine whether
> >         a child die's parent is a module and treat the child
> >         die as a static.
> >         (scan_partial_symbol): Support the DW_TAG_module tag.
> >         (add_partial_symbol): Support the DW_TAG_module tag.
> >         (process_die): Supports the DW_TAG_module tag by
> >         treating it as a structure scope.
> >         (read_file_scope): Moved  and enhanced some of the code
> >          to create the new dwarf2_get_child_pc_bounds()
> >         function.
> >         (read_structure_scope): Now supports the DW_TAG_module
> >         tag as a class and handles module variables and
> >         functions/subroutines as static members.
> >         (new_symbol): Now supports the DW_TAG_module tag and
> >         adds a module symbol to the global symbol list.
> >         (read_die_type): Now supports the DW_TAG_module tag
> >         as a structure scope.Index: dwarf2read.c