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

Michael Eager eager at eagercon.com
Wed Mar 9 11:51:54 PST 2016


On 03/09/2016 11:35 AM, Adrian Prantl wrote:
>
>> On Mar 9, 2016, at 8:36 AM, Michael Eager <eager at eagercon.com> wrote:
>>
>> On 03/04/2016 01:12 PM, Adrian Prantl wrote:
>>> I have a best-practice kind of question:
>>>
>>> The x86_64 System V ABI passes floating point values in the xmm0, xmm1, ... 128-bit SSE vector registers. I’m wondering what the correct DWARF v4 (lacking the DWARF 5 type conversions) expression for a 32-bit float in xmm0 is.
>>>
>>> Given the following program:
>>>
>>> float return_float() __attribute__((noinline)) { return 3.14f; }
>>>
>>> int main(int argc, char** argv) {
>>>    float f = return_float();
>>>    return (int)f;
>>> }
>>>
>>> Clang (-O1) currently produces the following DWARF for the variable f:
>>>
>>>   DW_TAG_variable
>>>     DW_AT_location( reg17 )   // xmm0 = 17
>>>     DW_AT_name( "f" )
>>>     DW_AT_decl_file( "test.c" )
>>>     DW_AT_decl_line( 8 )
>>>     DW_AT_type( {0x0000004a} ( float ) )
>>>
>>> Which causes LLDB to complain that the size of register xmm0 (128 Bits) is different from the size of f (32 Bits). I wonder who is wrong? Is LLDB being too strict, or should clang actually emit something like DW_OP_reg 17 (xmm0) DW_OP_piece 4 to make it abundantly clear that only the lower 32 bits of the vector register are interesting?
>>
>> How is the "float" type described?
>>
>> 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:
>
> Shouldn’t the container be orthogonal to the base type? How would this work with location lists (the same variable might be once in a 128-bit container, then spilled onto the stack, or a constant)?

Types in programming languages (such as float, int, structs, etc.) are
mapped onto the actual physical representation in the hardware.  This mapping
is described by the DWARF base type.  Base types are *not* the same as a type in
a programming language.

Location lists describe where the *value* of a variable may be
found during execution.  Location lists and variable definitions are
orthogonal.

What your DWARF describes is a variable which always lives in xmm0,
not one which is temporarily loaded into xmm0 during execution.  That's
not a common situation and probably not what you intended.

If a variable is ephimeral, and doesn't have a static existence
which can be described by a location expression, then I don't think
that you should have a DW_AT_location.  You may have a location list
which describes where the variable's *value* may be found during execution.


>
> -- adrian
>
>>
>>   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".
>>
>>
>> --
>> Michael Eager	 eager at eagercon.com
>> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
>
>


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



More information about the Dwarf-Discuss mailing list