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

[Daniel Jacobowitz <drow@false.org>]

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

> - 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?

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

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

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

-- 
Daniel Jacobowitz
CodeSourcery