This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [10/15] Basic value access routines
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: dje at google dot com (Doug Evans)
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 15 Jun 2009 18:58:53 +0200 (CEST)
- Subject: Re: [10/15] Basic value access routines
Doug Evans wrote:
> On Tue, Jun 9, 2009 at 8:19 AM, Ulrich Weigand<uweigand@de.ibm.com> wrote:
> > Hello,
> >
> > a number of core data conversion routines deeply buried in the
> > call chain implicitly use current_gdbarch to determine the format
> > of the data (address/pointer conversion, floating point formats).
> >
> > This patch adds an explicit gdbarch argument to the following
> > routines to eliminate that use, and updates all call sites:
> >
> > - unpack_long/unpack_double/unpack_pointer/pack_long
> > - extract_typed_address/store_typed_address/read_memory_typed_address
> > - extract_typed_floating/store_typed_floating/convert_typed_floating
> > - floatformat_from_type
>
> Can a struct type (or struct main_type) ever be associated with more
> than one architecture?
> [And if they can, is that correct given things like struct
> main_type.fields, struct type.length (and a few others)?]
>
> And if a struct type (or struct main_type) can (or should) only be
> associated with one architecture can we make it so that we can obtain
> the architecture given the type?
> That would seem to simplify things.
That was one of main design questions of this whole effort. The problems
with associating a gdbarch with a type (and subsequently using the arch
of a value's type as the arch of the value) is that:
- We have architecture-independent types (e.g. builtin_type_void,
builtin_type_int32 etc.), and last time we discussed this, the
consensus was that we want to keep this option
- The bulk of types is read in from symbol files -- these could be
associated with the generic objfile arch at this point, but that
is not sufficient as a value arch. For example, the objfile arch
does not contain specific register number associations; those are
only determined by a run-time arch from the target. For values
refering to registers, we need the latter however.
> [I realize there's type->main_type->objfile->gdbarch, but it's not
> clear to me that this will always be the correct one to use. Maybe it
> is.
> I also realize struct main_type is space critical, struct type is not
> marked as such but maybe it is too.
> I'd still hate to lose the simplicity gained by being able to
> determine an arch given just the type.
> Maybe there's a way to have both.]
Those are additional minor issues; the type structures are indeed
space critical, and the main_type->objfile pointer is not always set
(e.g. for builtin types), but we could use a union of a objfile
pointer and a gdbarch pointer. That major problems are the ones
described above -- at the time a type is allocated, we generally
do not know the correct architecture to use for values of this type.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com