From aprantl@apple.com  Fri Mar  4 21:12:39 2016
From: aprantl@apple.com (Adrian Prantl)
Date: Fri, 04 Mar 2016 13:12:39 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
	vector registers
Message-ID: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>

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?

-- adrian


From ccoutant@gmail.com  Fri Mar  4 21:50:23 2016
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 4 Mar 2016 13:50:23 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
Message-ID: <CAJimCsHeSWYX5b8=aza9SU5RFaZDQzXZQ2_PJ_Z8AkC-06t1Rg@mail.gmail.com>

>  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?

I would think that clang is right, and LLDB is wrong. It would be
silly to require the producer to use a longer representation that
essentially means the same thing. DW_OP_piece isn't meant to say that
you're only using part of the register -- it's meant for when part of
a larger *value* is in the register (whether the whole register or
part of it). Indeed, using DW_OP_piece leaves you in the same
situation -- with 32 bits placed in a 128-bit register.

How is this any different from saying a char variable is in a 32-bit register?

It's up to the ABI to define how smaller values are placed within a register.

-cary


From brock.wyma@intel.com  Fri Mar  4 21:51:40 2016
From: brock.wyma@intel.com (Wyma, Brock)
Date: Fri, 4 Mar 2016 21:51:40 +0000
Subject: [Dwarf-Discuss] Representing the location of smaller values
	in	vector registers
In-Reply-To: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
Message-ID: <E0A152731D43AF4A87A6B34CC193FBBB7C2BF15B@ORSMSX108.amr.corp.intel.com>

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: Dwarf-Discuss [mailto:dwarf-discuss-bounces@lists.dwarfstd.org] On Behalf Of Adrian Prantl
Sent: Friday, March 4, 2016 4:13 PM
To: dwarf-discuss at lists.dwarfstd.org
Subject: [Dwarf-Discuss] Representing the location of smaller values in vector registers

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?

-- adrian
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss at lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


From Paul_Robinson@playstation.sony.com  Fri Mar  4 22:00:22 2016
From: Paul_Robinson@playstation.sony.com (Robinson, Paul)
Date: Fri, 4 Mar 2016 22:00:22 +0000
Subject: [Dwarf-Discuss] Representing the location of smaller values
	in	vector registers
In-Reply-To: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEAD2C57609@USCULXMSG08.am.sony.com>

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, not subdividing a register.
--paulr

> -----Original Message-----
> From: Dwarf-Discuss [mailto:dwarf-discuss-bounces at lists.dwarfstd.org] On
> Behalf Of Adrian Prantl
> Sent: Friday, March 04, 2016 1:13 PM
> To: dwarf-discuss at lists.dwarfstd.org
> Subject: [Dwarf-Discuss] Representing the location of smaller values in
> vector registers
> 
> 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?
> 
> -- adrian
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


From aprantl@apple.com  Fri Mar  4 22:05:32 2016
From: aprantl@apple.com (Adrian Prantl)
Date: Fri, 04 Mar 2016 14:05:32 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEAD2C57609@USCULXMSG08.am.sony.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<E3B07FDB86BFF041819DC057DEED8FEAD2C57609@USCULXMSG08.am.sony.com>
Message-ID: <17DD7FEC-7E48-4BC9-86F1-1C772A791196@apple.com>


> On Mar 4, 2016, at 2:00 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> 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_piece is really meant for assembling partial values in different
> places, not subdividing a register.

I agree! I?ve been wanting to clean this up for a while now, I hope I?ll get to this soon.

thanks everyone for your feedback!
adrian


> --paulr
> 
>> -----Original Message-----
>> From: Dwarf-Discuss [mailto:dwarf-discuss-bounces at lists.dwarfstd.org] On
>> Behalf Of Adrian Prantl
>> Sent: Friday, March 04, 2016 1:13 PM
>> To: dwarf-discuss at lists.dwarfstd.org
>> Subject: [Dwarf-Discuss] Representing the location of smaller values in
>> vector registers
>> 
>> 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?
>> 
>> -- adrian
>> _______________________________________________
>> Dwarf-Discuss mailing list
>> Dwarf-Discuss at lists.dwarfstd.org
>> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



From arnez@linux.vnet.ibm.com  Wed Mar  9 11:35:06 2016
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Wed, 09 Mar 2016 12:35:06 +0100
Subject: [Dwarf-Discuss] Representing the location of smaller values in
	vector registers
In-Reply-To: <CAJimCsHeSWYX5b8=aza9SU5RFaZDQzXZQ2_PJ_Z8AkC-06t1Rg@mail.gmail.com>
	(Cary Coutant's message of "Fri, 4 Mar 2016 13:50:23 -0800")
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<CAJimCsHeSWYX5b8=aza9SU5RFaZDQzXZQ2_PJ_Z8AkC-06t1Rg@mail.gmail.com>
Message-ID: <m3d1r328b9.fsf@oc1027705133.ibm.com>

On Fri, Mar 04 2016, Cary Coutant wrote:

> It's up to the ABI to define how smaller values are placed within a register.

Right, that seems to be the common understanding.  Maybe the confusion
arose because the standard does not explicitly make this statement.  Or
did I miss it?

Also, I wonder whether everybody is on the same page as to what this
really means.  Consider the following questions:

* What if the object is too large for the given register?  For instance,
  can the ABI map the object to a register pair?

* Is DW_OP_regx(n) followed by DW_OP_piece(size of object type) always
  equivalent to omitting the DW_OP_piece operation?

Answers are welcome, since I'm currently trying to fix various issues
with GDB's handling of composite location descriptions.  More questions
about DWARF pieces came up as well:

  https://sourceware.org/ml/gdb/2016-01/msg00013.html

-- 
Andreas Arnez



From eager@eagercon.com  Wed Mar  9 16:36:44 2016
From: eager@eagercon.com (Michael Eager)
Date: Wed, 9 Mar 2016 08:36:44 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
Message-ID: <56E0511C.9040107@eagercon.com>

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:

   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



From dblaikie@gmail.com  Wed Mar  9 16:39:53 2016
From: dblaikie@gmail.com (David Blaikie)
Date: Wed, 9 Mar 2016 08:39:53 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E0511C.9040107@eagercon.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
Message-ID: <CAENS6EsfOK30yiLuAWhtLwerFK=HMAESym1+sdNKgRsensYEJQ@mail.gmail.com>

On Mar 9, 2016 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:
>
>   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".

After you suggesting that this float type would be used only for floats in
register and a different float type would be used for floats in memory?

I'm not sure how that would be used to describe a single variable that at
some points in its lifetime resides in memory and at others in register.

>
>
> --
> Michael Eager    eager at eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
>
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160309/0f0b75b4/attachment.htm>


From jakub@redhat.com  Wed Mar  9 17:33:23 2016
From: jakub@redhat.com (Jakub Jelinek)
Date: Wed, 9 Mar 2016 18:33:23 +0100
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E0511C.9040107@eagercon.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
Message-ID: <20160309173323.GP3017@tucnak.redhat.com>

On Wed, Mar 09, 2016 at 08:36:44AM -0800, Michael Eager wrote:
> 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:
> 
>   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".

I don't think this can really work.  A particular variable (etc., whatever
has type) can have just one type, while whether it lives in a larger
container or not really depends on where the value lives.
The same variable could live in one .debug_loc range in memory
(where it certainly can't pretend it lives in a larger container, because it
does not, it is 32-bit there), or when in some other range it lives in
a general purpose register (which can be 32-bit or 64-bit and either fits in
there exactly, or is passed in the low bits of that), or in %xmm* register
(128-bit container, but, actually sometimes 256-bit and other times 512-bit
container).  I'd say LLDB is just broken to complain about this.  The ABI
specifies what it means when a float lives in memory, or in GPRs, or in
XMM/YMM/ZMM registers.

	Jakub


From eager@eagercon.com  Wed Mar  9 17:57:21 2016
From: eager@eagercon.com (Michael Eager)
Date: Wed, 9 Mar 2016 09:57:21 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <20160309173323.GP3017@tucnak.redhat.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<20160309173323.GP3017@tucnak.redhat.com>
Message-ID: <56E06401.40404@eagercon.com>

On 03/09/2016 09:33 AM, Jakub Jelinek wrote:
> On Wed, Mar 09, 2016 at 08:36:44AM -0800, Michael Eager wrote:
>> 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:
>>
>>    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".
>
> I don't think this can really work.  A particular variable (etc., whatever
> has type) can have just one type, while whether it lives in a larger
> container or not really depends on where the value lives.
> The same variable could live in one .debug_loc range in memory
> (where it certainly can't pretend it lives in a larger container, because it
> does not, it is 32-bit there), or when in some other range it lives in
> a general purpose register (which can be 32-bit or 64-bit and either fits in
> there exactly, or is passed in the low bits of that), or in %xmm* register
> (128-bit container, but, actually sometimes 256-bit and other times 512-bit
> container).  I'd say LLDB is just broken to complain about this.  The ABI
> specifies what it means when a float lives in memory, or in GPRs, or in
> XMM/YMM/ZMM registers.

My comment was based on the DWARF in Adrian's email, which describes
a 32-bit floating point variable allocated to a 128-bit register.  Adrian's
DWARF doesn't describe a 32-bit variable in memory which is loaded into a
larger register during the course of expression evaluation, which would
be described by a location list.

A 32-variable stored in a 32-bit memory location may have a location list
which specifies that the value may be found in particular registers (either
larger or smaller) during it's lifetime.  That would be a different description
in DWARF.


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


From dblaikie@gmail.com  Wed Mar  9 18:00:48 2016
From: dblaikie@gmail.com (David Blaikie)
Date: Wed, 9 Mar 2016 10:00:48 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E06401.40404@eagercon.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<20160309173323.GP3017@tucnak.redhat.com>
	<56E06401.40404@eagercon.com>
Message-ID: <CAENS6Es_nP5H-sm5Yu+-_1SkMewvMCdSG9YptBE8-EZ6rLirJQ@mail.gmail.com>

On Wed, Mar 9, 2016 at 9:57 AM, Michael Eager <eager at eagercon.com> wrote:

> On 03/09/2016 09:33 AM, Jakub Jelinek wrote:
>
>> On Wed, Mar 09, 2016 at 08:36:44AM -0800, Michael Eager wrote:
>>
>>> 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:
>>>
>>>    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".
>>>
>>
>> I don't think this can really work.  A particular variable (etc., whatever
>> has type) can have just one type, while whether it lives in a larger
>> container or not really depends on where the value lives.
>> The same variable could live in one .debug_loc range in memory
>> (where it certainly can't pretend it lives in a larger container, because
>> it
>> does not, it is 32-bit there), or when in some other range it lives in
>> a general purpose register (which can be 32-bit or 64-bit and either fits
>> in
>> there exactly, or is passed in the low bits of that), or in %xmm* register
>> (128-bit container, but, actually sometimes 256-bit and other times
>> 512-bit
>> container).  I'd say LLDB is just broken to complain about this.  The ABI
>> specifies what it means when a float lives in memory, or in GPRs, or in
>> XMM/YMM/ZMM registers.
>>
>
> My comment was based on the DWARF in Adrian's email, which describes
> a 32-bit floating point variable allocated to a 128-bit register.  Adrian's
> DWARF doesn't describe a 32-bit variable in memory which is loaded into a
> larger register during the course of expression evaluation, which would
> be described by a location list.
>
> A 32-variable stored in a 32-bit memory location may have a location list
> which specifies that the value may be found in particular registers (either
> larger or smaller) during it's lifetime.  That would be a different
> description
> in DWARF.


Why would it be useful to say that an entry in a location list cannot
always be used as a direct location for a variable? (what if the location
list only includes registers - should the type then be changed to the
representation you're suggesting? That seems awkward for producers and
doesn't seem to help consumers)


>
>
>
> --
> Michael Eager    eager at eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160309/490cb733/attachment.htm>


From John.DelSignore@roguewave.com  Wed Mar  9 18:24:37 2016
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Wed, 9 Mar 2016 13:24:37 -0500
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <20160309173323.GP3017@tucnak.redhat.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>	<56E0511C.9040107@eagercon.com>
	<20160309173323.GP3017@tucnak.redhat.com>
Message-ID: <56E06A65.8010105@roguewave.com>

An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160309/553c726c/attachment.htm>


From jakub@redhat.com  Wed Mar  9 18:30:11 2016
From: jakub@redhat.com (Jakub Jelinek)
Date: Wed, 9 Mar 2016 19:30:11 +0100
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E06A65.8010105@roguewave.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<20160309173323.GP3017@tucnak.redhat.com>
	<56E06A65.8010105@roguewave.com>
Message-ID: <20160309183011.GQ3017@tucnak.redhat.com>

On Wed, Mar 09, 2016 at 01:24:37PM -0500, John DelSignore wrote:
> I agree completely with Jakub. Defining multiple "float" types that
> have varying byte-sizes, bit-sizes, and bit-offsets seems like a big
> mistake to me.
>
> The debugger has to know the ABI conventions for the target platform.
> It's unavoidable. Hopefully,  for ISVs like us, the ABI is "standard"
> and all of the compilers for a given platform follow the ABI
> conventions. Knowing the ABI conventions for the platform is especially
> important when the debugger is asked to call functions in the target
> process, which is something that DWARF does not describe at all.
> Passing float and double actual parameters to target function requires
> the debugger know if the values goes on the stack, in a register, or is
> split between the stack and a register (yes, this does happen).

Note that this isn't just about float and XMM registers, I don't see how
that is different from say a char variable living in a x86_64 GPR
(it is again the low 8 bits of a 64-bit register), or int variable in GPR
(again, low 32 bits of a 64-bit register).  How is that different from
low 32 or 64-bits of a {128,256,512}-bit register (depending on the HW
AVX or AVX512f support)?  In all cases it is just DW_OP_reg*.

	Jakub


From John.DelSignore@roguewave.com  Wed Mar  9 18:50:00 2016
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Wed, 9 Mar 2016 13:50:00 -0500
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <20160309183011.GQ3017@tucnak.redhat.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<20160309173323.GP3017@tucnak.redhat.com>
	<56E06A65.8010105@roguewave.com>
	<20160309183011.GQ3017@tucnak.redhat.com>
Message-ID: <56E07058.8090302@roguewave.com>

An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160309/ac40673b/attachment.htm>


From eager@eagercon.com  Wed Mar  9 19:20:38 2016
From: eager@eagercon.com (Michael Eager)
Date: Wed, 9 Mar 2016 11:20:38 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <CAENS6Es_nP5H-sm5Yu+-_1SkMewvMCdSG9YptBE8-EZ6rLirJQ@mail.gmail.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<20160309173323.GP3017@tucnak.redhat.com>
	<56E06401.40404@eagercon.com>
	<CAENS6Es_nP5H-sm5Yu+-_1SkMewvMCdSG9YptBE8-EZ6rLirJQ@mail.gmail.com>
Message-ID: <56E07786.2020108@eagercon.com>

On 03/09/2016 10:00 AM, David Blaikie wrote:
>
>
> On Wed, Mar 9, 2016 at 9:57 AM, Michael Eager <eager at eagercon.com <mailto:eager at eagercon.com>> wrote:
>
>     On 03/09/2016 09:33 AM, Jakub Jelinek wrote:
>
>         On Wed, Mar 09, 2016 at 08:36:44AM -0800, Michael Eager wrote:
>
>             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:
>
>                 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".
>
>
>         I don't think this can really work.  A particular variable (etc., whatever
>         has type) can have just one type, while whether it lives in a larger
>         container or not really depends on where the value lives.
>         The same variable could live in one .debug_loc range in memory
>         (where it certainly can't pretend it lives in a larger container, because it
>         does not, it is 32-bit there), or when in some other range it lives in
>         a general purpose register (which can be 32-bit or 64-bit and either fits in
>         there exactly, or is passed in the low bits of that), or in %xmm* register
>         (128-bit container, but, actually sometimes 256-bit and other times 512-bit
>         container).  I'd say LLDB is just broken to complain about this.  The ABI
>         specifies what it means when a float lives in memory, or in GPRs, or in
>         XMM/YMM/ZMM registers.
>
>
>     My comment was based on the DWARF in Adrian's email, which describes
>     a 32-bit floating point variable allocated to a 128-bit register.  Adrian's
>     DWARF doesn't describe a 32-bit variable in memory which is loaded into a
>     larger register during the course of expression evaluation, which would
>     be described by a location list.
>
>     A 32-variable stored in a 32-bit memory location may have a location list
>     which specifies that the value may be found in particular registers (either
>     larger or smaller) during it's lifetime.  That would be a different description
>     in DWARF.
>
>
> Why would it be useful to say that an entry in a location list cannot always be used as a direct
> location for a variable? (what if the location list only includes registers - should the type then
> be changed to the representation you're suggesting? That seems awkward for producers and doesn't
> seem to help consumers)

I didn't say that.

Variable definitions describe where the variable is defined.
If the size of the variable is different from the size of
the container, it should be described as such.

This has nothing to do with location lists.


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


From eager@eagercon.com  Wed Mar  9 19:25:40 2016
From: eager@eagercon.com (Michael Eager)
Date: Wed, 9 Mar 2016 11:25:40 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E07058.8090302@roguewave.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<20160309173323.GP3017@tucnak.redhat.com>
	<56E06A65.8010105@roguewave.com>
	<20160309183011.GQ3017@tucnak.redhat.com>
	<56E07058.8090302@roguewave.com>
Message-ID: <56E078B4.9020803@eagercon.com>

On 03/09/2016 10:50 AM, John DelSignore wrote:
> I think what you are saying, and I agree, is that the type of a variable is orthogonal to where (or
> how) the variable is stored. DWARF should not muddy the type entries with attributes that attempt to
> describe how a variable is stored somewhere. As I already said, the debugger has to know the ABI
> conventions for the target platforms it supports, and knowing how a float is stored in an XMM
> register, or a char is stored an x86_64 GPR, is part of the ABI specification.

DWARF describes where variables are allocated and their base type.
A base type explicitly describes the size of the type and the
size of its container.

Type representations such as "integer" or "float" are attributes of the
base type, and are orthogonal to descriptions of where the variable
is allocated.

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


From fche@redhat.com  Wed Mar  9 19:26:36 2016
From: fche@redhat.com (Frank Ch. Eigler)
Date: Wed, 9 Mar 2016 14:26:36 -0500
Subject: [Dwarf-Discuss] Representing the location of smaller values in
	vector registers
In-Reply-To: <56E07786.2020108@eagercon.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<20160309173323.GP3017@tucnak.redhat.com>
	<56E06401.40404@eagercon.com>
	<CAENS6Es_nP5H-sm5Yu+-_1SkMewvMCdSG9YptBE8-EZ6rLirJQ@mail.gmail.com>
	<56E07786.2020108@eagercon.com>
Message-ID: <20160309192636.GA26181@redhat.com>

Hi -

On Wed, Mar 09, 2016 at 11:20:38AM -0800, Michael Eager wrote:
> [...]
> Variable definitions describe where the variable is defined.
> If the size of the variable is different from the size of
> the container, it should be described as such.
> 
> This has nothing to do with location lists.

... except to the extent that the same variable may have different
containers, so representation base-types, at different code locations?

- FChE


From eager@eagercon.com  Wed Mar  9 19:35:04 2016
From: eager@eagercon.com (Michael Eager)
Date: Wed, 9 Mar 2016 11:35:04 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <20160309192636.GA26181@redhat.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<20160309173323.GP3017@tucnak.redhat.com>
	<56E06401.40404@eagercon.com>
	<CAENS6Es_nP5H-sm5Yu+-_1SkMewvMCdSG9YptBE8-EZ6rLirJQ@mail.gmail.com>
	<56E07786.2020108@eagercon.com> <20160309192636.GA26181@redhat.com>
Message-ID: <56E07AE8.2000707@eagercon.com>

On 03/09/2016 11:26 AM, Frank Ch. Eigler wrote:
> Hi -
>
> On Wed, Mar 09, 2016 at 11:20:38AM -0800, Michael Eager wrote:
>> [...]
>> Variable definitions describe where the variable is defined.
>> If the size of the variable is different from the size of
>> the container, it should be described as such.
>>
>> This has nothing to do with location lists.
>
> ... except to the extent that the same variable may have different
> containers, so representation base-types, at different code locations?

When a variable (say an 8-bit char) is loaded into a 32-bit
register, the location list can represent that the *value* can
now be found in that register.  That does not mean that the
allocation for the variable has changed, nor does DWARF
create multiple descriptions for a variable which may (at
certain times in it's lifetime) be loaded into a register.

Location lists and variable declarations are orthogonal.
Adrian's DWARF excerpt was for a variable declaration;
most of the discussion has been about location lists.

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


From aprantl@apple.com  Wed Mar  9 19:35:28 2016
From: aprantl@apple.com (Adrian Prantl)
Date: Wed, 09 Mar 2016 11:35:28 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E0511C.9040107@eagercon.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
Message-ID: <BBF61568-3C0F-4AAE-8CFF-94FE7EFAD75A@apple.com>


> 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)?

-- 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



From wiml@omnigroup.com  Wed Mar  9 19:46:48 2016
From: wiml@omnigroup.com (Wim Lewis)
Date: Wed, 9 Mar 2016 11:46:48 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values
	in	vector registers
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEAD2C57609@USCULXMSG08.am.sony.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<E3B07FDB86BFF041819DC057DEED8FEAD2C57609@USCULXMSG08.am.sony.com>
Message-ID: <D8D1B943-3D12-4A78-B7F5-883437DE99F6@omnigroup.com>


On Mar 4, 2016, at 2:00 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> 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_piece is really meant for assembling partial values in different
> places, not subdividing a register.


The introduction to the "piece" opcodes says that subdividing a register is part of their intended use (as Jakub Jelinek says, you have a similar situation if you're storing "char"s in a wider register):

> 2.6.1.2 Composite Location Descriptions
> 
> A composite location description describes an object or value which may be contained in part of a register or stored in more than one location. [....] There may be one or more composition operations in a single composite location description.  

Using a single composition operation to describe a value which is located in part of a register is explicitly an intended case for the piece operators. DW_OP_piece can be used to specify a value shorter than an entire register when "the placement of the piece within that register is defined by the ABI"; DW_OP_bit_piece can be used "when the piece to be assembled into a value [...] is not at the start of a register".

So it seems to me that Clang's output (reg; piece) is correct; I think GCC's is also reasonable, since the ABI defines how to store a float32 in a 128-bit register. 




From eager@eagercon.com  Wed Mar  9 19:51:54 2016
From: eager@eagercon.com (Michael Eager)
Date: Wed, 9 Mar 2016 11:51:54 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <BBF61568-3C0F-4AAE-8CFF-94FE7EFAD75A@apple.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<BBF61568-3C0F-4AAE-8CFF-94FE7EFAD75A@apple.com>
Message-ID: <56E07EDA.1020409@eagercon.com>

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



From ccoutant@gmail.com  Wed Mar  9 22:53:40 2016
From: ccoutant@gmail.com (Cary Coutant)
Date: Wed, 9 Mar 2016 14:53:40 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E0511C.9040107@eagercon.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
Message-ID: <CAJimCsGzcVxqKGbkZ8mBg_x+OJ-HhJt13=7tjp9V4hz1zGUuBw@mail.gmail.com>

> 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.

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.

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.

-cary


From eager@eagercon.com  Thu Mar 10 01:24:16 2016
From: eager@eagercon.com (Michael Eager)
Date: Wed, 9 Mar 2016 17:24:16 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <CAJimCsGzcVxqKGbkZ8mBg_x+OJ-HhJt13=7tjp9V4hz1zGUuBw@mail.gmail.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<CAJimCsGzcVxqKGbkZ8mBg_x+OJ-HhJt13=7tjp9V4hz1zGUuBw@mail.gmail.com>
Message-ID: <56E0CCC0.7080302@eagercon.com>

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


From eager@eagercon.com  Thu Mar 10 01:32:34 2016
From: eager@eagercon.com (Michael Eager)
Date: Wed, 9 Mar 2016 17:32:34 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E0CCC0.7080302@eagercon.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<CAJimCsGzcVxqKGbkZ8mBg_x+OJ-HhJt13=7tjp9V4hz1zGUuBw@mail.gmail.com>
	<56E0CCC0.7080302@eagercon.com>
Message-ID: <56E0CEB2.3050300@eagercon.com>

On 03/09/2016 05:24 PM, Michael Eager wrote:
> 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?

Oops.  There is a DWARF expression in the DW_AT_location.

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


From ccoutant@gmail.com  Thu Mar 10 01:57:10 2016
From: ccoutant@gmail.com (Cary Coutant)
Date: Wed, 9 Mar 2016 17:57:10 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E0CCC0.7080302@eagercon.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<CAJimCsGzcVxqKGbkZ8mBg_x+OJ-HhJt13=7tjp9V4hz1zGUuBw@mail.gmail.com>
	<56E0CCC0.7080302@eagercon.com>
Message-ID: <CAJimCsHfnSErn2bjc2_TRiy8W2mLDrQcH9ZnhT5R_r439ZWfCg@mail.gmail.com>

>> 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.

No, it didn't, and I don't know why you keep suggesting that it makes
a difference. Whether a variable has a single location or a list of
locations depends solely on what kinds of optimizations occur.
Everyone understands that. The only reason location lists entered the
discussion was because you claimed that the placement of the value in
a register could be described with the data_bit_offset attribute in
the base type. That might seem plausible at first, but breaks down as
soon as you consider what happens when you do have a location list --
you'd need one base type to describe the variable when it's in a
larger register, and another base type to describe it when it's not.
This is what David and the others were trying to point out.

> 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.

It's a simple example. It's perfectly plausible for a variable to live
its entire lifetime in a single register. But when it does, the
placement of the value in that register is *not* to be described with
a data_bit_offset attribute in its base type. That wouldn't work, and
it's not what that attribute is for.

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

Irrelevant.

> 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.

As I said, location lists only came up as a counter-example to your
suggestion to use the data_bit_offset attribute of the base type.

We're not discussing "how ABIs tell you how to interpret [location
lists]". We're discussing whether the consumer is expected to turn to
the ABI to find out how a smaller value is stored in a larger
register. It's relevant with or without a location list. It's relevant
to any register location description, whether in a single location
description or a location list, whether in a simple location
description or a compound location description.

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

Good.

>> 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?

[I saw your followup, but it doesn't change the answer...]

Adrian was looking for guidance to understand what the spec says about
placement of smaller values in larger registers. He found some
guidance in the section on DW_OP_piece, but nowhere else, leading him
to ask if clang should have been using DW_OP_piece to describe this
case. That simple statement under DW_OP_piece should also apply under
the DW_OP_reg operators, and if it had been there, it would have been
much clearer that DW_OP_piece is totally unnecessary for his example.

-cary


From Paul_Robinson@playstation.sony.com  Thu Mar 10 02:05:56 2016
From: Paul_Robinson@playstation.sony.com (Robinson, Paul)
Date: Thu, 10 Mar 2016 02:05:56 +0000
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <56E0CCC0.7080302@eagercon.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<CAJimCsGzcVxqKGbkZ8mBg_x+OJ-HhJt13=7tjp9V4hz1zGUuBw@mail.gmail.com>
	<56E0CCC0.7080302@eagercon.com>
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEAD2C6398C@USCULXMSG08.am.sony.com>

> 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.

DW_AT_location provides a location description.  It might be single, it
might be a list.  I guess I'm having a hard time understanding why the form 
of the location description should affect how the type is described.

I'm also not clear where this distinction between the variable's location
and the variable's value's location comes from.  Location descriptions are
specified in terms of the location of the object itself, not the location
of its value.  In a location list, it's not the location of the value that 
moves around, it's the location of the object that moves around.

The only time we talk about location descriptions that produce a value is 
when something has no location at all, and we use DW_OP_implicit_value or 
DW_OP_stack_value, neither of which is in play here.

--paulr



From fche@redhat.com  Thu Mar 10 02:21:00 2016
From: fche@redhat.com (Frank Ch. Eigler)
Date: Wed, 9 Mar 2016 21:21:00 -0500
Subject: [Dwarf-Discuss] Representing the location of smaller values in
	vector registers
In-Reply-To: <CAJimCsHfnSErn2bjc2_TRiy8W2mLDrQcH9ZnhT5R_r439ZWfCg@mail.gmail.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<CAJimCsGzcVxqKGbkZ8mBg_x+OJ-HhJt13=7tjp9V4hz1zGUuBw@mail.gmail.com>
	<56E0CCC0.7080302@eagercon.com>
	<CAJimCsHfnSErn2bjc2_TRiy8W2mLDrQcH9ZnhT5R_r439ZWfCg@mail.gmail.com>
Message-ID: <20160310022100.GB26181@redhat.com>

Hi, Cary -

> [...]  We're not discussing "how ABIs tell you how to interpret
> [location lists]". We're discussing whether the consumer is expected
> to turn to the ABI to find out how a smaller value is stored in a
> larger register. [...]

Given that the ABI constraints apply only at function call boundaries,
it's possible that a compiler would choose to store values in a
different way in the function's interior.  For example, it could put
several small scalars into a wider register.

- FChE


From ccoutant@gmail.com  Thu Mar 10 03:42:51 2016
From: ccoutant@gmail.com (Cary Coutant)
Date: Wed, 9 Mar 2016 19:42:51 -0800
Subject: [Dwarf-Discuss] Representing the location of smaller values in
 vector registers
In-Reply-To: <20160310022100.GB26181@redhat.com>
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<CAJimCsGzcVxqKGbkZ8mBg_x+OJ-HhJt13=7tjp9V4hz1zGUuBw@mail.gmail.com>
	<56E0CCC0.7080302@eagercon.com>
	<CAJimCsHfnSErn2bjc2_TRiy8W2mLDrQcH9ZnhT5R_r439ZWfCg@mail.gmail.com>
	<20160310022100.GB26181@redhat.com>
Message-ID: <CAJimCsFdPxWeU0hqh_MeeqEZ4Q=ZTRE6k_9YbSzdvEN9dqjgUA@mail.gmail.com>

We're straying even further off topic now...

>> [...]  We're not discussing "how ABIs tell you how to interpret
>> [location lists]". We're discussing whether the consumer is expected
>> to turn to the ABI to find out how a smaller value is stored in a
>> larger register. [...]
>
> Given that the ABI constraints apply only at function call boundaries,

Sure, calling conventions and register usage and such apply only at
function call boundaries, but an ABI covers far more than just that.
Whatever it says for representation of values in registers would apply
in general...

> it's possible that a compiler would choose to store values in a
> different way in the function's interior.  For example, it could put
> several small scalars into a wider register.

...and we have DW_OP_bit_piece for exceptional circumstances like that.

-cary


From arnez@linux.vnet.ibm.com  Thu Mar 10 09:00:31 2016
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Thu, 10 Mar 2016 10:00:31 +0100
Subject: [Dwarf-Discuss] Representing the location of smaller values in
	vector registers
In-Reply-To: <CAJimCsHfnSErn2bjc2_TRiy8W2mLDrQcH9ZnhT5R_r439ZWfCg@mail.gmail.com>
	(Cary Coutant's message of "Wed, 9 Mar 2016 17:57:10 -0800")
References: <E9A973B8-C621-44A4-BE37-380762FFA59F@apple.com>
	<56E0511C.9040107@eagercon.com>
	<CAJimCsGzcVxqKGbkZ8mBg_x+OJ-HhJt13=7tjp9V4hz1zGUuBw@mail.gmail.com>
	<56E0CCC0.7080302@eagercon.com>
	<CAJimCsHfnSErn2bjc2_TRiy8W2mLDrQcH9ZnhT5R_r439ZWfCg@mail.gmail.com>
Message-ID: <m3ziu6zp00.fsf@oc1027705133.ibm.com>

On Thu, Mar 10 2016, Cary Coutant wrote:

> Adrian was looking for guidance to understand what the spec says about
> placement of smaller values in larger registers. He found some
> guidance in the section on DW_OP_piece, but nowhere else, leading him
> to ask if clang should have been using DW_OP_piece to describe this
> case. That simple statement under DW_OP_piece should also apply under
> the DW_OP_reg operators, and if it had been there, it would have been
> much clearer that DW_OP_piece is totally unnecessary for his example.

Right, and I think now that we're at it, we should pay some attention to
the details.  For instance: Can a DWARF consumer assume that DW_OP_reg*
followed by DW_OP_piece(size of object type) is always equivalent to
omitting the piece operation?

As a related topic, I think that the current description of the piece
operations should be improved as well.  While the placement of
DW_OP_piece in a register is clearly stated to depend on the ABI, the
statement about DW_OP_bit_piece sounds very different: "...the offset is
from the least significant bit end of the register."  In the latter case
DWARF obviously prescribes a *specific* placement scheme, independent
from the ABI, for no apparent reason, and without defining the term
"least significant bit end".

I stumbled upon this because I noticed that the implementation of piece
operations in GDB is completely broken, and apart from fixing the
various obvious bugs, I'm still trying to figure out how the piece
operations should really behave.

For a more in-depth discussion about issues with register pieces see my
article here:

  https://sourceware.org/ml/gdb/2016-01/msg00013.html

-- 
Andreas Arnez



From ryan@bissell.org  Sun Mar 13 04:03:47 2016
From: ryan@bissell.org (Ryan Bissell)
Date: Sat, 12 Mar 2016 22:03:47 -0600
Subject: [Dwarf-Discuss] DWARF 5 Standard release update?
Message-ID: <CAGZHuvmwZT=UGy_c4qcZ8TqkXKwVrpP=BN8jzvxjHKwnkYH9jQ@mail.gmail.com>

Hello,

It's been a while since I've seen this topic broached:  is there an
updated estimate for public release of the DWARF Version 5 standard?

Thanks,

</ryan>


From jonas@lophus.org  Sat Mar 19 11:46:37 2016
From: jonas@lophus.org (Jonas H.)
Date: Sat, 19 Mar 2016 12:46:37 +0100
Subject: [Dwarf-Discuss] .cfi_offset questions
Message-ID: <17B11CFA-1ABD-4E02-8C61-34B14A03FE00@lophus.org>

Hi!

I hope this is the right mailing list to ask this kind of question.

I?m working on a edu/research compiler that has yet to be equipped with DWARF info. Unlike GCC/Clang/? it doesn?t have spill slots that are ?constant? within a procedure, i.e. may procedure code like this:

_main:
  ?
  je B
A:
  movl %edi,  -8(%rbp) # EDI spill slot: -8
  ?
  jmp C
B:
  movl %eax,  -8(%rbp)
  movl %edi, -16(%rbp) # EDI spill slot: -16
  jmp C
C:
  ?

Is this supported by the DWARF .cfi_offset directives at all, and if so, how? Generally speaking, what?s the ?scope?/?validity period?/?life span? of such directive?

As an example, if C were to raise an exception and we?d use stack unwinding, how could the unwinder find the old/callee-saved EDI value?

Thanks
Jonas


From francesco.zappa.nardelli@gmail.com  Thu Mar 24 13:56:21 2016
From: francesco.zappa.nardelli@gmail.com (Francesco Zappa Nardelli)
Date: Thu, 24 Mar 2016 14:56:21 +0100
Subject: [Dwarf-Discuss] _starting address_ in eh_frame FDE encoding
Message-ID: <CALCBA_H5HKJjwnuma5-hDbY+AoWp+HDtNrRtoVxzLSxF56SzDA@mail.gmail.com>

Dear all

I have a question about the FDE encoding in eh_frame (and not dwarf_frame)
tables.

This document (I could not find a better description of eh_frame)

  http://www.airs.com/blog/archives/460

states that:

  "An FDE starts with the length and ID described above, and then continues
as follows.   1 The _starting address_ to which this FDE applies. This is
encoded using the FDE encoding specified by the associated CIE.?

In a sample elf file, the associated CIE augmentation data state reports:

   DW_EH_PE_pcrel, DW_EH_PE_sdata4

and the untranslated starting address value in the FDE is fffffe88
(according to readelf this should be translated to 4004d0).  I do not
understand what ?value is PC relative? means here, as we are actually
defining the range of PC values.

Can somebody explain me how to interpret this _starting address_ field?

Thank you in advance.

-francesco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160324/a8f65f39/attachment.htm>


From ccoutant@gmail.com  Thu Mar 24 14:47:04 2016
From: ccoutant@gmail.com (Cary Coutant)
Date: Thu, 24 Mar 2016 07:47:04 -0700
Subject: [Dwarf-Discuss] _starting address_ in eh_frame FDE encoding
In-Reply-To: <CALCBA_H5HKJjwnuma5-hDbY+AoWp+HDtNrRtoVxzLSxF56SzDA@mail.gmail.com>
References: <CALCBA_H5HKJjwnuma5-hDbY+AoWp+HDtNrRtoVxzLSxF56SzDA@mail.gmail.com>
Message-ID: <CAJimCsHu9HYNbrCkuQF-is_Yw4qGGPfd8W24UsNZtbgLCCOvMA@mail.gmail.com>

> I have a question about the FDE encoding in eh_frame (and not dwarf_frame)
> tables.
>
> This document (I could not find a better description of eh_frame)
>
>   http://www.airs.com/blog/archives/460

The official description of the .eh_frame section, with a description
of the augmentation string and what the various DW_EH_PE values mean,
can be found in the relevant psABI document for your architecture.

> states that:
>
>   "An FDE starts with the length and ID described above, and then continues
> as follows.   1 The _starting address_ to which this FDE applies. This is
> encoded using the FDE encoding specified by the associated CIE.?
>
> In a sample elf file, the associated CIE augmentation data state reports:
>
>    DW_EH_PE_pcrel, DW_EH_PE_sdata4
>
> and the untranslated starting address value in the FDE is fffffe88
> (according to readelf this should be translated to 4004d0).  I do not
> understand what ?value is PC relative? means here, as we are actually
> defining the range of PC values.
>
> Can somebody explain me how to interpret this _starting address_ field?

PC-relative simply means that the value is not an absolute address,
but rather an offset relative to itself (i.e., the address of the
field that contains the value. The value you read there was
0xfffffe88, which, according to the augmentation string, is a signed
4-byte value, or -0x178. If you add that to the address of the
starting address field itself, you'll get the actual starting address,
which readelf has computed as 0x4004d0. Working backwards, that
implies that your FDE started at 400640, with the starting address
field at 0x400648.

-cary


From jonas@lophus.org  Thu Mar 24 14:50:08 2016
From: jonas@lophus.org (Jonas Haag)
Date: Thu, 24 Mar 2016 15:50:08 +0100
Subject: [Dwarf-Discuss] .cfi_offset questions
In-Reply-To: <17B11CFA-1ABD-4E02-8C61-34B14A03FE00@lophus.org>
References: <17B11CFA-1ABD-4E02-8C61-34B14A03FE00@lophus.org>
Message-ID: <C6A86C40-B547-4301-8D0A-DB17F8FA55FB@lophus.org>

> 
> On 19 Mar 2016, at 12:46, Jonas H. <jonas at lophus.org> wrote:
> 
> I?m working on a edu/research compiler that has yet to be equipped with DWARF info. Unlike GCC/Clang/? it doesn?t have spill slots that are ?constant? within a procedure, i.e. may procedure code like this:
> 
>  ?
> 
> Is this supported by the DWARF .cfi_offset directives at all, and if so, how? Generally speaking, what?s the ?scope?/?validity period?/?life span? of such directive?

Wondering about the lack of response here ? is this a stupid question; didn?t I do my homework? I couldn?t find any discussion about this in the archives. I?ve also already looked for an answer in the lib unwind mailing list archives.

Jonas


From ccoutant@gmail.com  Thu Mar 24 15:35:25 2016
From: ccoutant@gmail.com (Cary Coutant)
Date: Thu, 24 Mar 2016 08:35:25 -0700
Subject: [Dwarf-Discuss] .cfi_offset questions
In-Reply-To: <C6A86C40-B547-4301-8D0A-DB17F8FA55FB@lophus.org>
References: <17B11CFA-1ABD-4E02-8C61-34B14A03FE00@lophus.org>
	<C6A86C40-B547-4301-8D0A-DB17F8FA55FB@lophus.org>
Message-ID: <CAJimCsH16hSV0tQGfo9v17D5wRUuzuXa7epZP1E3px5i9PBYRQ@mail.gmail.com>

>> I?m working on a edu/research compiler that has yet to be equipped with DWARF info. Unlike GCC/Clang/? it doesn?t have spill slots that are ?constant? within a procedure, i.e. may procedure code like this:
>>
>>  ?
>>
>> Is this supported by the DWARF .cfi_offset directives at all, and if so, how? Generally speaking, what?s the ?scope?/?validity period?/?life span? of such directive?

What you're describing is "shrink-wrapping". GCC does supports this
optimization, and I think that LLVM is currently working on it.
DWARF's .debug_frame section certainly supports this, and by extension
the .eh_frame section would also support it.

The .cfi_offset directives are described in the gas manual, and you
might find more help on their use, if you need it, on the binutils
mailing list. In general, the scope of a .cfi_offset directive extends
from its use forward until cancelled by a new CFI directive for that
same register, or until the end of the procedure. So in your example,
you could place them as follows:

_main:
  ?
  je B
A:
  movl %edi,  -8(%rbp) # EDI spill slot: -8
  .cfi_offset 5, -8
  ?
  jmp C
B:
  .cfi_restore 5   # This cancels the CFI directive above.
  movl %eax,  -8(%rbp)
  .cfi_offset 0, -8
  movl %edi, -16(%rbp) # EDI spill slot: -16
  .cfi_offset 5, -16
  jmp C
C:
  ?

But at C, you have a problem. You have two paths that both join at C,
but the register save state is different in each path. Theoretically,
you could have some common code at C that doesn't care, then split
apart again (using the same condition) to restore the registers, but
you can't describe the register save state for that common code, which
means that an exception occurring in that range will not work
correctly.

It's fine to have different regions of code with different register
save states, but it's a bad idea to have two paths join without
compensation code at the end of one or both paths to match the states.
For example, you could restore the spilled registers at the end of
each path (which is probably more typical for a shrink-wrapped
function).

-cary


From jonas@lophus.org  Thu Mar 24 15:50:02 2016
From: jonas@lophus.org (Jonas Haag)
Date: Thu, 24 Mar 2016 16:50:02 +0100
Subject: [Dwarf-Discuss] .cfi_offset questions
In-Reply-To: <CAJimCsH16hSV0tQGfo9v17D5wRUuzuXa7epZP1E3px5i9PBYRQ@mail.gmail.com>
References: <17B11CFA-1ABD-4E02-8C61-34B14A03FE00@lophus.org>
	<C6A86C40-B547-4301-8D0A-DB17F8FA55FB@lophus.org>
	<CAJimCsH16hSV0tQGfo9v17D5wRUuzuXa7epZP1E3px5i9PBYRQ@mail.gmail.com>
Message-ID: <FE5CA10C-0B1D-496B-B757-25D62D3F840D@lophus.org>


> On 24 Mar 2016, at 16:35, Cary Coutant <ccoutant at gmail.com> wrote:
> 
> It's fine to have different regions of code with different register
> save states, but it's a bad idea to have two paths join without
> compensation code at the end of one or both paths to match the states.
> For example, you could restore the spilled registers at the end of
> each path (which is probably more typical for a shrink-wrapped
> function).

Thank you! That?s exactly the information I was looking for.

By saying that .debug_frame supports shrink wrapping, do you also mean that it supports the ?two paths join with different register state? case? Which means it?s only a matter of the .cfi_xxx directives, and if I were to build the .debug_frame/.eh_frame section by hand I would be fine?

Jonas



From ccoutant@gmail.com  Thu Mar 24 16:01:40 2016
From: ccoutant@gmail.com (Cary Coutant)
Date: Thu, 24 Mar 2016 09:01:40 -0700
Subject: [Dwarf-Discuss] .cfi_offset questions
In-Reply-To: <FE5CA10C-0B1D-496B-B757-25D62D3F840D@lophus.org>
References: <17B11CFA-1ABD-4E02-8C61-34B14A03FE00@lophus.org>
	<C6A86C40-B547-4301-8D0A-DB17F8FA55FB@lophus.org>
	<CAJimCsH16hSV0tQGfo9v17D5wRUuzuXa7epZP1E3px5i9PBYRQ@mail.gmail.com>
	<FE5CA10C-0B1D-496B-B757-25D62D3F840D@lophus.org>
Message-ID: <CAJimCsHPG+ib3=gBWj7u9mnEzURY2Ww3mVacXAONyreMA0HAww@mail.gmail.com>

> By saying that .debug_frame supports shrink wrapping, do you also mean that it supports the ?two paths join with different register state? case? Which means it?s only a matter of the .cfi_xxx directives, and if I were to build the .debug_frame/.eh_frame section by hand I would be fine?

No, I don't believe that it can in general. There's no way to express
a conditional "if p then DW_CFA_def_offset else
DW_CFA_def_same_value", for example. If a register is spilled to the
stack in both paths, but at different offsets, you could encode it
with DW_CFA_def_offset, using a DWARF expression that evaluates to
different values based on a condition, but this technique would be
limited to the case where you could use DW_CFA_def_offset for both
paths. I think this would also lead to some undesirable bulk in your
.debug_frame or .eh_frame sections. And I'm not actually sure whether
the unwinder (Which unwinder? There are several!) completely supports
DWARF expressions in that context.

-cary


From eager@eagercon.com  Sat Mar 26 16:49:48 2016
From: eager@eagercon.com (Michael Eager)
Date: Sat, 26 Mar 2016 09:49:48 -0700
Subject: [Dwarf-Discuss] .cfi_offset questions
In-Reply-To: <17B11CFA-1ABD-4E02-8C61-34B14A03FE00@lophus.org>
References: <17B11CFA-1ABD-4E02-8C61-34B14A03FE00@lophus.org>
Message-ID: <56F6BDAC.7060001@eagercon.com>

On 03/19/2016 04:46 AM, Jonas H. wrote:
> Hi!
>
> I hope this is the right mailing list to ask this kind of question.
>
> I?m working on a edu/research compiler that has yet to be equipped with DWARF info. Unlike GCC/Clang/? it doesn?t have spill slots that are ?constant? within a procedure, i.e. may procedure code like this:
>
> _main:
>    ?
>    je B
> A:
>    movl %edi,  -8(%rbp) # EDI spill slot: -8
>    ?
>    jmp C
> B:
>    movl %eax,  -8(%rbp)
>    movl %edi, -16(%rbp) # EDI spill slot: -16
>    jmp C
> C:
>    ?
>
> Is this supported by the DWARF .cfi_offset directives at all, and if so, how? Generally speaking, what?s the ?scope?/?validity period?/?life span? of such directive?

I'm a bit unclear on your question.

CFI doesn't depend on spill slots being constant or, in fact, know anything
about spill slots.  The CFI information tracks the location of register values,
and describes that at some PC value a register (eg, %edi) may be found at a
specified location, and at another PC value it may be found at a different location.

The "scope" (if there is such a thing) for a CFI directive is from the PC
where it is specified until some following PC which indicates the same register
may be found at a different location, or the end of the CFI.

> As an example, if C were to raise an exception and we?d use stack unwinding, how could the unwinder find the old/callee-saved EDI value?

Look up the value's location as described in the CFI for the PC value.

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



From francesco.zappa.nardelli@gmail.com  Tue Mar 29 16:01:32 2016
From: francesco.zappa.nardelli@gmail.com (Francesco Zappa Nardelli)
Date: Tue, 29 Mar 2016 18:01:32 +0200
Subject: [Dwarf-Discuss] _starting address_ in eh_frame FDE encoding
In-Reply-To: <CAJimCsHu9HYNbrCkuQF-is_Yw4qGGPfd8W24UsNZtbgLCCOvMA@mail.gmail.com>
References: <CALCBA_H5HKJjwnuma5-hDbY+AoWp+HDtNrRtoVxzLSxF56SzDA@mail.gmail.com>
	<CAJimCsHu9HYNbrCkuQF-is_Yw4qGGPfd8W24UsNZtbgLCCOvMA@mail.gmail.com>
Message-ID: <CALCBA_FOYyRU=cC7xTTaxX-gfTujNLeS2zJYWJhkqB5-OtyoDw@mail.gmail.com>

Cary, thanks for your reply!  I am still confused though, can we check this
example together?

Here is an annotated hexdump for the first CIE and FDE of an eh_frame table:

$ hexdump -C -s 0x580 -n 658 foo2
00000580  14 00 00 00 00 00 00 00  01 7a 52 00 01 78 10 01
          length    | ID        |  v  aug    | af df rr la

00000590  1b 0c 07 08 90 01 07 10  14 00 00 00 1c 00 00 00
          *| opcds  .     .     || length    | ptr to CIE|
*FDE encoding (aug = R) : 1b = PC_REL, sdata4

000005a0  00 fe ff ff 2a 00 00 00  00 00 00 00 00 00 00 00
          strt_addr*|                                   ||

The CIE augmentation data state states:

  DW_EH_PE_pcrel, DW_EH_PE_sdata4

The untranslated starting address in the FDE (noted strt_addr) is

  fffffe00 (that is -200 in hex, -512 in dec)

which, according to readelf must be translated to

  pc=00000000004003a0

The offset since the beginning of the eh_frame of the strt_addr field is
32, and

 $ readelf -S foo2
There are 34 section headers, starting at offset 0xc20:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
...
  [16] .eh_frame         PROGBITS         0000000000400590  00000590
       0000000000000114  0000000000000000   A       0     0     8

In hex,  400590 + 20 = 4005b0, is this the ?PC address? that we should
consider when we parse the PCREL start address?  If yes, 4005b0 - 200 =
4003b0, but we should have got 4003a0.  Can you point me to where I am
wrong?

Thank you again.

Best
-francesco



On Thu, Mar 24, 2016 at 3:47 PM, Cary Coutant <ccoutant at gmail.com> wrote:

> > I have a question about the FDE encoding in eh_frame (and not
> dwarf_frame)
> > tables.
> >
> > This document (I could not find a better description of eh_frame)
> >
> >   http://www.airs.com/blog/archives/460
>
> The official description of the .eh_frame section, with a description
> of the augmentation string and what the various DW_EH_PE values mean,
> can be found in the relevant psABI document for your architecture.
>
> > states that:
> >
> >   "An FDE starts with the length and ID described above, and then
> continues
> > as follows.   1 The _starting address_ to which this FDE applies. This is
> > encoded using the FDE encoding specified by the associated CIE.?
> >
> > In a sample elf file, the associated CIE augmentation data state reports:
> >
> >    DW_EH_PE_pcrel, DW_EH_PE_sdata4
> >
> > and the untranslated starting address value in the FDE is fffffe88
> > (according to readelf this should be translated to 4004d0).  I do not
> > understand what ?value is PC relative? means here, as we are actually
> > defining the range of PC values.
> >
> > Can somebody explain me how to interpret this _starting address_ field?
>
> PC-relative simply means that the value is not an absolute address,
> but rather an offset relative to itself (i.e., the address of the
> field that contains the value. The value you read there was
> 0xfffffe88, which, according to the augmentation string, is a signed
> 4-byte value, or -0x178. If you add that to the address of the
> starting address field itself, you'll get the actual starting address,
> which readelf has computed as 0x4004d0. Working backwards, that
> implies that your FDE started at 400640, with the starting address
> field at 0x400648.
>
> -cary
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160329/75166f6a/attachment.htm>


From martin.galvan@tallertechnologies.com  Wed Mar 30 21:49:40 2016
From: martin.galvan@tallertechnologies.com (Martin Galvan)
Date: Wed, 30 Mar 2016 18:49:40 -0300
Subject: [Dwarf-Discuss] DWARF 5 Standard release update?
In-Reply-To: <CAGZHuvmwZT=UGy_c4qcZ8TqkXKwVrpP=BN8jzvxjHKwnkYH9jQ@mail.gmail.com>
References: <CAGZHuvmwZT=UGy_c4qcZ8TqkXKwVrpP=BN8jzvxjHKwnkYH9jQ@mail.gmail.com>
Message-ID: <1459374580-8024-1-git-send-email-martin.galvan@tallertechnologies.com>

Hi, I'm also interested in this. Are there any news?


From francesco.zappa.nardelli@gmail.com  Thu Mar 31 08:43:45 2016
From: francesco.zappa.nardelli@gmail.com (Francesco Zappa Nardelli)
Date: Thu, 31 Mar 2016 10:43:45 +0200
Subject: [Dwarf-Discuss] _starting address_ in eh_frame FDE encoding
In-Reply-To: <CALCBA_FOYyRU=cC7xTTaxX-gfTujNLeS2zJYWJhkqB5-OtyoDw@mail.gmail.com>
References: <CALCBA_H5HKJjwnuma5-hDbY+AoWp+HDtNrRtoVxzLSxF56SzDA@mail.gmail.com>
	<CAJimCsHu9HYNbrCkuQF-is_Yw4qGGPfd8W24UsNZtbgLCCOvMA@mail.gmail.com>
	<CALCBA_FOYyRU=cC7xTTaxX-gfTujNLeS2zJYWJhkqB5-OtyoDw@mail.gmail.com>
Message-ID: <CALCBA_GN19PxEGUfLtrEtD0PRPjt05meqm6bt0gLJ-E47Uvg-w@mail.gmail.com>

Dear all

> I am still confused though, can we check this example together?

Sorry for the noise, I made a silly mistake and the addresses in the
hexdump, which are off by 0x10.  Problem solved, thank you for the help!

-francesco


> Here is an annotated hexdump for the first CIE and FDE of an eh_frame
> table:
>
> $ hexdump -C -s 0x580 -n 658 foo2
> 00000580  14 00 00 00 00 00 00 00  01 7a 52 00 01 78 10 01
>           length    | ID        |  v  aug    | af df rr la
>
> 00000590  1b 0c 07 08 90 01 07 10  14 00 00 00 1c 00 00 00
>           *| opcds  .     .     || length    | ptr to CIE|
> *FDE encoding (aug = R) : 1b = PC_REL, sdata4
>
> 000005a0  00 fe ff ff 2a 00 00 00  00 00 00 00 00 00 00 00
>           strt_addr*|                                   ||
>
> The CIE augmentation data state states:
>
>   DW_EH_PE_pcrel, DW_EH_PE_sdata4
>
> The untranslated starting address in the FDE (noted strt_addr) is
>
>   fffffe00 (that is -200 in hex, -512 in dec)
>
> which, according to readelf must be translated to
>
>   pc=00000000004003a0
>
> The offset since the beginning of the eh_frame of the strt_addr field is
> 32, and
>
>  $ readelf -S foo2
> There are 34 section headers, starting at offset 0xc20:
>
> Section Headers:
>   [Nr] Name              Type             Address           Offset
>        Size              EntSize          Flags  Link  Info  Align
> ...
>   [16] .eh_frame         PROGBITS         0000000000400590  00000590
>        0000000000000114  0000000000000000   A       0     0     8
>
> In hex,  400590 + 20 = 4005b0, is this the ?PC address? that we should
> consider when we parse the PCREL start address?  If yes, 4005b0 - 200 =
> 4003b0, but we should have got 4003a0.  Can you point me to where I am
> wrong?
>
> Thank you again.
>
> Best
> -francesco
>
>
>
> On Thu, Mar 24, 2016 at 3:47 PM, Cary Coutant <ccoutant at gmail.com> wrote:
>
>> > I have a question about the FDE encoding in eh_frame (and not
>> dwarf_frame)
>> > tables.
>> >
>> > This document (I could not find a better description of eh_frame)
>> >
>> >   http://www.airs.com/blog/archives/460
>>
>> The official description of the .eh_frame section, with a description
>> of the augmentation string and what the various DW_EH_PE values mean,
>> can be found in the relevant psABI document for your architecture.
>>
>> > states that:
>> >
>> >   "An FDE starts with the length and ID described above, and then
>> continues
>> > as follows.   1 The _starting address_ to which this FDE applies. This
>> is
>> > encoded using the FDE encoding specified by the associated CIE.?
>> >
>> > In a sample elf file, the associated CIE augmentation data state
>> reports:
>> >
>> >    DW_EH_PE_pcrel, DW_EH_PE_sdata4
>> >
>> > and the untranslated starting address value in the FDE is fffffe88
>> > (according to readelf this should be translated to 4004d0).  I do not
>> > understand what ?value is PC relative? means here, as we are actually
>> > defining the range of PC values.
>> >
>> > Can somebody explain me how to interpret this _starting address_ field?
>>
>> PC-relative simply means that the value is not an absolute address,
>> but rather an offset relative to itself (i.e., the address of the
>> field that contains the value. The value you read there was
>> 0xfffffe88, which, according to the augmentation string, is a signed
>> 4-byte value, or -0x178. If you add that to the address of the
>> starting address field itself, you'll get the actual starting address,
>> which readelf has computed as 0x4004d0. Working backwards, that
>> implies that your FDE started at 400640, with the starting address
>> field at 0x400648.
>>
>> -cary
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160331/fa70197f/attachment.htm>


