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>, 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: Mon, 6 Oct 2008 16:09:28 -0400
- 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> <20080919221221.GA23372@adacore.com> <20080926125754.GC21287@caradoc.them.org>
> > 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?
>
> Agreed. I would suggest LOC_COMPUTED as the role model, except I
> don't see where to stash an ops pointer. Maybe in TYPE_SPECIFIC, or
> is that ugly?
I think it is kind of ugly, and i tried to think about it for a while,
but I don't see many possible solutions if we don't want to increase
the gdbtype struct size. Ideally, I would like to stash the ops pointer
in the field structure itself, but there is no room either. The
alternative I had in mind is hard-code the fact that the field a DWARF
block and not use an ops pointer at all to get the field position.
The code is not as generic, but we can separate this part of the design
we're a little stuck on from the implementation of support for field
positions encoded as DWARF blocks without too much loss of quality.
Once we are decided on how to store the ops pointer, enhancing the
framework should be fairly mechanical...
--
Joel