From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31291 invoked by alias); 15 Aug 2002 22:11:58 -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 31163 invoked from network); 15 Aug 2002 22:11:57 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 15 Aug 2002 22:11:57 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17fSqU-0003dv-00; Thu, 15 Aug 2002 17:11:58 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17fSqt-0004YO-00; Thu, 15 Aug 2002 18:12:23 -0400 Date: Thu, 15 Aug 2002 15:11:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Petr Sorfa , "gdb-patches@sources.redhat.com" Subject: Re: [RFA] Patch for supportinf DW_TAG_module / FORTRAN modules Message-ID: <20020815221223.GA17334@nevyn.them.org> Mail-Followup-To: Jim Blandy , Petr Sorfa , "gdb-patches@sources.redhat.com" References: <3D34883C.4AAC7EE@caldera.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00387.txt.bz2 On Thu, Aug 15, 2002 at 04:31:15PM -0500, Jim Blandy wrote: > > 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? > > 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. > > 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. > > Perhaps we should introduce LOC_MODULE, or TYPE_CODE_MODULE. > > 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. That's my opinion. Fortran modules are obvious candidates for a real scope; when we have real scopes they can do that, and for now we can handle them like classes. I like the principle of the patch (though I haven't looked at the patch itself). -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer