This is the mail archive of the
mailing list for the GDB project.
Re: Per-type architecture (Re: [10/15] Basic value access routines)
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: dje at google dot com (Doug Evans), gdb-patches at sourceware dot org
- Date: Tue, 23 Jun 2009 19:00:24 +0200 (CEST)
- Subject: Re: Per-type architecture (Re: [10/15] Basic value access routines)
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
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. */
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
> 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.
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE