Re: [10/15] Basic value access routines

[Doug Evans <dje at google dot com>]

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.

[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.]

Thoughts?