From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8720 invoked by alias); 19 Sep 2008 22:13:01 -0000 Received: (qmail 8712 invoked by uid 22791); 19 Sep 2008 22:13:00 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 19 Sep 2008 22:12:26 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0430B2A964B; Fri, 19 Sep 2008 18:12:24 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7Q73Nf7Hpn3E; Fri, 19 Sep 2008 18:12:23 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 73F282A9647; Fri, 19 Sep 2008 18:12:23 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 3E658E7ACD; Fri, 19 Sep 2008 15:12:21 -0700 (PDT) Date: Fri, 19 Sep 2008 22:13:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org, Tobias Burnus , Ulrich Weigand , Jim Blandy , jimb@codesourcery.com Subject: Re: [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays] Message-ID: <20080919221221.GA23372@adacore.com> References: <20080818111120.GE16894@adacore.com> <200808181553.m7IFrG3w005270@d12av02.megacenter.de.ibm.com> <48A59B3C.9050801@net-b.de> <20080818111120.GE16894@adacore.com> <20080907115637.GA12939@host0.dyn.jankratochvil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080907115637.GA12939@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00425.txt.bz2 > Also I do not understand why exist all the macros like this one at all: > #define TYPE_MAIN_TYPE(thistype) (thistype)->main_type > Why we cannot use it expanded? This way it is always one (or more) > "tags"-jump (VIM ctrl-]) indirections while navigating the source files. Personally, I find them to be very useful to quickly find who is using field "main_type" in struct type. > 2008-09-07 Jan Kratochvil > > Split two-bit STATIC_KIND to two separate bitfield single bits. > * gdbtypes.h (struct main_type ): Split to ... > (struct main_type , ): ... here. > (FIELD_STATIC_KIND): Split to ... > (FIELD_BIT0, FIELD_BIT1): ... here. > (SET_FIELD_BITPOS): New. > (SET_FIELD_PHYSNAME, SET_FIELD_PHYSADDR, TYPE_FIELD_STATIC) > (TYPE_FIELD_STATIC_HAS_ADDR): Update for the split. > (TYPE_FIELD_STATIC_KIND): Remove. > (TYPE_FIELD_STATIC_HAS_NAME): New. > * coffread.c, dwarf2read.c, eval.c, gdbtypes.c, mdebugread.c: Update > throughout. It would be interesting to hear what others think, but I don't really like the idea of splitting the 2-bit static_kind field into two one-bit fields named bit0 & bit1. I just find it obscures things even more. The first goal, as I understand it, is to be able to extend range types so that the bounds can be DWARF blocks. Here is a thought: Rename the static_kind field into "field_loc_kind" which would be an enum with 4 possible values: loc_in_bitpos, loc_in_physaddr, loc_in_physname, and loc_in_block. The names are yet to be decided, but it's just to give you an idea of what they would mean. 4 possible values mean that, for now, we have room in the 2-bit field to store it. This "field_loc_kind" would then be checked for the types were the loc kind can be ambiguous (range types would be the next addition to the current list). Next, we add a new field in the "loc" union that would contain a pointer to the dwarf block, and probably create some kind of routine to create these range types. After that, we can update the DWARF reader to handle DWARF blocks for range type bounds, and finally update Fortran to make use of them. What do others think? -- Joel