From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4589 invoked by alias); 26 Aug 2002 23:01:35 -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 4582 invoked from network); 26 Aug 2002 23:01:34 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 26 Aug 2002 23:01:34 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 3345C10AAA; Mon, 26 Aug 2002 18:59:40 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15722.45787.968594.993458@localhost.redhat.com> Date: Mon, 26 Aug 2002 16:01:00 -0000 To: Jim Blandy Cc: Petr Sorfa , "gdb-patches@sources.redhat.com" Subject: Re: [RFA] Patch for supportinf DW_TAG_module / FORTRAN modules In-Reply-To: References: <3D34883C.4AAC7EE@caldera.com> <3D5D5221.D9854F8F@caldera.com> <3D5D6156.6B6E38A@caldera.com> X-SW-Source: 2002-08/txt/msg00873.txt.bz2 Jim Blandy writes: > Petr Sorfa writes: > > > Your patch is right, as far as I can see. In that paragraph I'm just > > > saying why I think the patch should work fine. In the next paragraph > > > I explain my reservations. > > Ok. > > > > > > > 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. > > > > > > If we're going to use a struct/class-like thingy to represent a > > > Fortran module, then we should at least add DECLARED_TYPE_MODULE (see > > > DECLARED_TYPE_CLASS, ... in gdbtypes.h). > > Will do. I think I had that done as well. > > > > > > > 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) > > > > > > I'm not sure I really want the C++ `std' namespace represented as a > > > struct type. > > Please ignore that suggestion, it was made in jest. But you are right, > > once namespace support it put in, it should be able to support FORTRAN > > modules. > > > > If I update the patch to use TYPE_CODE_MODULE and DECLARED_TYPE_CLASS, > > would you reconsider the patch? > > I'd like to hear Elena's comments on it, but if she thinks it's okay, > then I'll review the patch in detail. I think the using TYPE_CODE_MODULE and DECLARED_TYPE_CLASS will help in distinguishing the Fortran modules. I would prefer however is there were lots of new comments added to things like this, to make things clearer: ! if (cu_language == language_cplus || cu_language == language_fortran) { /* For C++, these implicitly act as typedefs as well. */ add_psymbol_to_list (pdi->name, strlen (pdi->name), and + case DW_TAG_module: + read_structure_scope (die, objfile, cu_header); + break; I don't nderstand the comment here: + case DW_TAG_module: + /* Read the module scope a structure. */ + read_structure_scope (die, objfile, cu_header); Elena