[Dwarf-Discuss] DWARF piece questions

[Andreas Arnez]

On Fri, Jan 27 2017, Cary Coutant wrote:

>>> I think the original intent of this wording was to describe the bit
>>> offset of a field within a structure, given the byte address of the
>>> beginning of the structure. Said bit offset would be the total number
>>> of bits occupied by preceding fields plus internal padding, as
>>> demonstrated in the big- and little-endian examples in D.2.8. We
>>> should never have implied that this bit numbering was meant to match
>>> the bit numbering convention used in the ABI specification.
>>
>> Unfortunately, that's exactly what DWARF says.
>
> But it's not what we meant, and we should fix it.
>
>>> This is not the only place we use this bit numbering convention -- we
>>> also use it for the DW_AT_data_bit_offset attribute, and it's defined
>>> in Section 5.7, with a reference to the examples in D.2.8.
>>
>> Also, not what we want.
>
> Why is this not what we want? There's really no better way to define a
> field's position within a structure.

I must admit, I have trouble following this discussion...

Maybe we can get more concrete?  Let's say a DWARF consumer is requested
to print a variable that has a composite DW_AT_location.  First it
concatenates the individual pieces into a destination buffer, to
represent the variable's value as if it were located in the program's
memory.  Then it uses its usual from-memory print function for the given
variable's type.

In that scenario, suppose that the DWARF consumer has already copied the
first p-1 pieces, whose bit sizes add up to k bits.  Next is the p'th
piece, which is described as a DW_OP_bit_piece (say) with offset m and
bit size n.  Now the DWARF consumer copies the bits for this piece to
the destination buffer with this pseudo-code:

    FOR i IN (0 .. n-1)
      COPY source_bit(m + i) TO dest_bit(k + i)

where source_bit() and dest_bit() somehow map an integer to a bit in the
underlying source- and destination object, respectively.

So, with this scenario in mind, I thought we were discussing how to
define the source_bit() mapping for the various flavors of underlying
objects (memory, register, stack value, indirect value), right?

And is it correct that for memory pieces source_bit() provides the same
relative mapping as dest_bit()?

And that dest_bit(j) addresses the same bit as DW_AT_data_bit_offset(j)?

And that DW_AT_data_bit_offset(j) addresses the same bit as the bit
field 'x' in the following C structure?

    struct bit_j
      {
        unsigned char : 1;
        [ ... ] /* (j-1) copies of the line above */
        unsigned char x : 1;
      };

--
Andreas