> On Mar 4, 2016, at 2:00 PM, Robinson, Paul
> wrote:
>
> I tried a CU with an int variable instead of float, and enough other
> stuff to keep it from being optimized away completely.
> gcc produced DW_OP_reg3, while Clang produced "DW_OP_reg3; DW_OP_piece 4"
> for the same variable.
>
> DW_OP
I tried a CU with an int variable instead of float, and enough other
stuff to keep it from being optimized away completely.
gcc produced DW_OP_reg3, while Clang produced "DW_OP_reg3; DW_OP_piece 4"
for the same variable.
DW_OP_piece is really meant for assembling partial values in different
places
If the variable exists in memory at esp + 4 then I would expect a debugger
wouldn't complain about memory from esp + 4 thru 0xfff..ff is larger than the
size of a float. It sounds like lldb is being too strict.
Brock Wyma
Intel Corporation
-Original Message-
From: Dwar
> 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( {0x004a} ( float ) )
>
> Which causes LLDB to complain that the size of register xmm0 (128 Bits) is
> different from the size of f (
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
