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
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
