Re: Lazy bitfields

[Daniel Jacobowitz <drow@false.org>]

On Thu, Feb 08, 2007 at 10:28:56AM -0500, Daniel Jacobowitz wrote:
> Second, I'm worried about the "offset" argument to
> value_primitive_field.  This was primarily for CHILL, due to a
> strange choice when generating or reading debug info, and it's
> possible that it's never non-zero any more, which would be nice.
> But if it ever is non-zero, this will break it.  It gets lumped
> in with value_offset so when you call unpack_field_as_long in
> value_fetch_lazy you can't pick it out again to apply it to the
> parent.
> 
> That's my only real concern with this patch; everything else
> looks OK.  I'm going to try to figure out if that argument is
> ever non-zero or if we can eliminate it now.

This is all very twisted.  I bet we could eliminate the non-zero
cases, but it would take some untangling - though the result would
be simpler than what we have now.  Here's a C++ test case:

struct A
{
  int x : 12;
  int y : 14;
};

struct A a;

struct pad
{
  int useless;
};

struct B : pad, A
{
  int no;
};

struct B b;

If you print out b.y, value_primitive_field will be called with an
offset of 4.  arg1 will be a value of type B, but arg_type will be
type A.  I think it should have passed a value of type A, instead
of trying to do two steps at once... but that's what it does now.

The difference between value_type (arg1) and arg_type is something else
I hadn't noticed before.  That means you're saving a fieldno into
arg_type but applying it to value_type (value_parent (val)), which
has a similar problem.

I think you can work around this in two ways.  We could fix all the
current jumping through hoops and eliminate the offset argument, or you
could avoid using the parent's type or fieldno.  You want value_bitsize
bits, from the parents contents plus a bit offset of:

   ((value_offset (val) - value_offset (value_parent (val))) * 8
    + value_bitpos (val))

The difference in the two offsets gives you back the 'offset' argument
to value_primitive_field plus the byte offset of the field, the
value_bitpos gives you the additional bit offset of the field.

You'd need something like unpack_field_as_long, but one which replaced
the type and fieldno arguments with field_type (for TYPE_UNSIGNED),
bitpos, and bitsize.

Did that make any sense at all?

-- 
Daniel Jacobowitz
CodeSourcery