Re: Per-type architecture (Re: [10/15] Basic value access routines)

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Daniel Jacobowitz wrote:
> On Tue, Jun 23, 2009 at 02:41:22AM +0200, Ulrich Weigand wrote:
> > - for values of bitfield type, the bitfield byte order (as you mention)
> 
> We don't actually need the architecture for this, given the type.  But
> that's only because the way we record this in types requires the
> architecture when building the type; I've seriously considered
> rearranging it so that the type was architecture neutral and the value
> architecture dependent.  But it seems too fragile to touch without a
> better reason...

We *do* need the architecture to interpret bitfield types; see e.g. the
comment in gdbtypes.h:

      /* Position of this field, counting in bits from start of
         containing structure.
         For gdbarch_bits_big_endian=1 targets, it is the bit offset to the MSB.
         For gdbarch_bits_big_endian=0 targets, it is the bit offset to the LSB.
         For a range bound or enum value, this is the value itself. */

      int bitpos;

and the various references to gdbarch_bits_big_endian (current_gdbarch)
in unpack_field_as_long, modify_field, etc.   There's no way to operate
on a bitfield value without knowledge of this property.

> > - for values of floating point type, the floating point format (which
> >   today is sometimes, but not always, attached to the type)
> 
> Huh, when isn't it attached to the type?

Most of the time :-)   In fact, none of the types created by symbol readers
ever has a non-NULL TYPE_FLOATFORMAT.  It is only set for builtin types
generated via gdbtypes.c:build_flt (and the builtin_type_ia64_ext special
case).  For every other type, the floatformat is computed on the fly in
floatformat_from_type via floatformat_from_length  (again consulting gdbarch
properties of current_gdbarch).

> > However, for the *first* set of properties it doesn't seem to make sense
> > to require this information to be provided apart from the value object;
> > there is just about nothing you can do with the value if you don't even
> > understand how to interpret its contents.
> 
> This is the part I'm not sure about.  An int32_t from a BE application
> and an int32_t from an LE application are clearly distinguished
> values, but I think they're of the same type.  However, I don't feel
> so strongly about this to object to your patch.

Well, I strongly feel that byte order needs to determinable from the *value*
object one way or the other.  Whether this is done by making byte order a
property of the value's *type*, or rather by making byte order a property of
the value itself in addition to its type, I don't feel very strongly about;
this seems to me to be more a question of what's more convenient to use.

If we decide to associate a gdbarch with a type anyway to cover the other
properties mentioned, then it seems simpler to use it for byte order too.
However, even then we could still have an additional byte-order property
of the value that would override the type's, if we think that necessary ...

> > For example, one class of such uses is to find some random type in order
> > to construct an index value to pass to value_subscript (or value_ptradd)
> > or the like.  We actually know the *offset* as numerical value, but finding
> > the *type* to form a value object out of the offset is hard.  In this case,
> > it seems to me the interface of our helper routines is simply ill-defined:
> > value_subscript does not even *look* at the type of the index operand, the
> > only thing it does to the value is calling value_as_long!  So simply changing
> > the interface to take a LONGEST instead of value fixes this class of problems
> > while making the callers simpler.
> 
> For my two cents, I would have preferred we had a uniform internal
> value/type system where everything operated on struct value.  Then you
> know exactly what any value_* routine expects: always value(s).
> That's why I wanted frame unwinding to use values instead of buffers.

I agree, but those naturally *have* types ...   I guess we can discuss this with
more specificity once I actually post patches about value_subscript etc.

> > This seems even uglier to me :-)  Maybe I'm just looking at this particular
> > target-description case a bit differently, but for me tdesc_type is not
> > "inventing a new ad-hoc representation of types", it is simply a 1:1 in-memory
> > representation of the XML contents without any GDB-specific reinterpretation
> > -- think something like "DOM tree" structures.  In fact, if it weren't that
> > we want to avoid excessive dependencies on XML libraries, I'd argue we should
> > just parse XML into a standard DOM tree representation as provided by those.
> 
> Good point.  Yes, I'd much preferred we had a DOM; I looked at several
> minimalist C DOM implementations, but couldn't find one that I trusted
> to work nearly as well as expat.  Since expat ended up external to the
> GDB source tree anyway, maybe it would have been wiser to pick GNOME's
> libxml2.
> 
> The duplication of type layouts bugs me, but let's go with it.
> Afterwards, I'll do a second merge into our internal tree and see what
> the extra type support looks like.

OK, thanks.  I've checked the patch in now.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com