From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32463 invoked by alias); 16 Aug 2002 19:15:15 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32443 invoked from network); 16 Aug 2002 19:15:13 -0000 Received: from unknown (HELO tetsuo.nj.caldera.com) (63.124.204.226) by sources.redhat.com with SMTP; 16 Aug 2002 19:15:13 -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 g7GJRTC13242; Fri, 16 Aug 2002 15:27:29 -0400 Message-ID: <3D5D5221.D9854F8F@caldera.com> Date: Fri, 16 Aug 2002 12:15:00 -0000 From: Petr Sorfa Organization: Caldera X-Accept-Language: en MIME-Version: 1.0 To: Jim Blandy CC: "gdb-patches@sources.redhat.com" Subject: Re: [RFA] Patch for supportinf DW_TAG_module / FORTRAN modules References: <3D34883C.4AAC7EE@caldera.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00443.txt.bz2 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 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 > > > > * 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