Re: [10/15] Basic value access routines

["Ulrich Weigand" <uweigand@de.ibm.com>]

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