This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Patch for supportinf DW_TAG_module / FORTRAN modules
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: Petr Sorfa <petrs at caldera dot com>,"gdb-patches at sources dot redhat dot com" <gdb-patches at sources dot redhat dot com>
- Date: Thu, 15 Aug 2002 18:12:23 -0400
- Subject: Re: [RFA] Patch for supportinf DW_TAG_module / FORTRAN modules
- References: <3D34883C.4AAC7EE@caldera.com> <vt21y8zu7vg.fsf@zenia.red-bean.com>
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