[Dwarf-Discuss] Representing the location of smaller values in vector registers

[Michael Eager]

On 03/09/2016 02:53 PM, Cary Coutant wrote:
>> A value which is contained in a register larger than the size of
>> the value should be described by a DW_TAG_base_type.  (DWARF 4,
>> Sect. 5.1, bottom of page 75).
>>
>> For a 32-bit float in a 128-bit container, use something like the following:
>>
>>    DW_TAG_base_type
>>      DW_AT_name "float"
>>      DW_AT_encoding DW_ATE_float
>>      DW_AT_byte_size 16
>>      DW_AT_bit_size 32
>>      DW_AT_data_bit_offset 0
>>
>> Note that there is no requirement that the names on base types
>> be unique.  There may be more than one with the name "float".
>
> Sorry, Michael, but you're just muddying the waters. The
> data_bit_offset attribute is used only when "the value of an object of
> the given type does not fully occupy the storage described by a byte
> size attribute." That is not the case here -- the original question
> was about a value of a type that does not fully occupy a register,
> which is a totally different question. We're just not going to expect
> (nor is it even physically possible in the DWARF representation) that
> the producer invent a different base type for each possible location
> where a variable might be stored. Whether it's a single location or a
> location list is irrelevant to the question, but the possibility that
> there may be a location list is what exposes the impracticality of
> your suggestion -- a variable can have only a single type, regardless
> of how many location list entries it has.

The DWARF did not include a location list.

Adrian's DWARF, as written, describes a variable allocated to a register.
Apparently permanently, or at least, within the current scope.  (I've seen
this in embedded code where a variable is assigned to a register.)  What
was likely intended is a location list which specifies where the variable's
*value* may be found, independent of where the variable was allocated.

Many optimizations eliminate allocating storage for a variable.  When this
happens, there isn't a DW_AT_location attribute.

If there had been a location list in Adrian's DWARF, the discussion about
location lists and how ABIs tell you how to interpret them might have been
on point.  Without a location list, I don't see the relevance.

> I think the rest of us agree that the proper answer is that the ABI
> defines how a value is stored in a register when the value is smaller
> than the register, and that clang is producing good DWARF for this
> example. Whether it's a 32-bit float in a 256-bit xmm register or an
> 8-bit char in a 64-bit general register, we let the ABI define the
> representation. In most cases, it's a natural representation that just
> falls out from the way the instruction set works, and no one really
> needs to give it much thought (e.g., store the value in the low-order
> bits of the register, possibly with zero- or sign-extension). In other
> cases, like some floating-point register files, a value is actually
> converted to a wider type when loaded into a register. At any rate, we
> have never attempted to describe those rules in the DWARF, and it
> would make little sense to try.

An ABI defines loading a value into a register from memory.  No one
(certainly not me) is trying to define those rules in DWARF.

> The source of the original uncertainty about representation of a
> smaller value in a larger register is probably that the DWARF spec
> *does* explicitly state, for DW_OP_piece, if "the piece is located in
> a register, but does not occupy the entire register, the placement of
> the piece within that register is defined by the ABI." But we make no
> such similar claim for simple register location descriptions. That led
> Adrian to wonder if he should be using DW_OP_piece. I think it's an
> oversight, easily clarified.

There are no DWARF expressions involved here.  What does the
description of DW_OP_piece have to do with a DWARF description
which doesn't use a DWARF expression?

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077