This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays]
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Tobias Burnus <burnus at net-b dot de>, Ulrich Weigand <uweigand at de dot ibm dot com>, Jim Blandy <jimb at red-bean dot com>, jimb at codesourcery dot com
- Date: Fri, 19 Sep 2008 15:12:21 -0700
- Subject: Re: [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays]
- 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>
> 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 <jan.kratochvil@redhat.com>
>
> Split two-bit STATIC_KIND to two separate bitfield single bits.
> * gdbtypes.h (struct main_type <static_kind>): Split to ...
> (struct main_type <bit0>, <bit1>): ... 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