On Fri, Jan 27 2017, Cary Coutant wrote:
>>> I think the original intent of this wording was to describe the bit
>>> offset of a field within a structure, given the byte address of the
>>> beginning of the structure. Said bit offset would be the total number
>>> of bits occupied by preceding field
On Fri, Jan 27 2017, Robinson, Paul wrote:
>> So, from a DWARF perspective, you'd expect that all libraries shall be
>> recompiled when migrating from an older x86-64 CPU to a newer one that
>> has AVX-512? Or, as in the z/Architecture case, from a zEC12 to a z13
>> system? You don't consider it
On 01/27/2017 04:55 PM, Cary Coutant wrote:
* Is "DW_OP_reg*" followed by "DW_OP_piece(size of object type)" always
equivalent to omitting the piece operation?
If sizeof(obj) == sizeof(reg) it is obviously.
If sizeof(obj) > sizeof(reg) the expression is malformed because there
are undefined b
On 01/27/2017 05:32 PM, Cary Coutant wrote:
How about if we define this in terms of a left shift instead of a bit
offset relative to the least-significant bit?
"If the location is a register, the value is shifted left by offset
bits within the register."
Extracting bits is conceptually clearer
On 01/27/2017 05:32 PM, Cary Coutant wrote:
> Why is this not what we want? There's really no better way to define a
> field's position within a structure.
Bit offset of a field
in a structure is one of the things that ABIs do (routinely?)
specify precisely.
--
Ubuntu is an African word meaning
>> I think the original intent of this wording was to describe the bit
>> offset of a field within a structure, given the byte address of the
>> beginning of the structure. Said bit offset would be the total number
>> of bits occupied by preceding fields plus internal padding, as
>> demonstrated in
On 01/27/2017 05:11 PM, Cary Coutant wrote:
I still haven't understood *why* DWARF insists on trying to establish a
universal register bit numbering scheme, and just for the definition of
DW_OP_bit_piece? I don't know of any other normative source that tries
this; and DWARF usually avoids going
>>> I still haven't understood *why* DWARF insists on trying to establish a
>>> universal register bit numbering scheme, and just for the definition of
>>> DW_OP_bit_piece? I don't know of any other normative source that tries
>>> this; and DWARF usually avoids going into such low-level detail, le
* Is "DW_OP_reg*" followed by "DW_OP_piece(size of object type)" always
equivalent to omitting the piece operation?
>>>
>>> If sizeof(obj) == sizeof(reg) it is obviously.
>>> If sizeof(obj) > sizeof(reg) the expression is malformed because there
>>> are undefined bits in the object that
> -Original Message-
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of Andreas Arnez
> Sent: Friday, January 27, 2017 11:16 AM
> To: Michael Eager
> Cc: DWARF Discussion; Ulrich Weigand
> Subject: Re: [Dwarf-Discuss] DWARF piece
On 01/27/2017 11:15 AM, Andreas Arnez wrote:
On Fri, Jan 27 2017, Michael Eager wrote:
On 01/27/2017 06:49 AM, Andreas Arnez wrote:
But if some "even less significant" bits were added (such as with
z/Architecture, where a newer release extended 64-bit FP-registers to
128-bit vectors), then the
On Thu, Jan 26 2017, Andrew Cagney wrote:
>> I thought your example specifically addressed DW_OP_piece (not
>> DW_OP_bit_piece), and that it illustrated the usefulness of involving
>> the resulting object's DW_AT_type into the ABI-dependent placement rule.
>> If that's what you meant, then the exa
On Fri, Jan 27 2017, Michael Eager wrote:
> On 01/27/2017 06:49 AM, Andreas Arnez wrote:
>> But if some "even less significant" bits were added (such as with
>> z/Architecture, where a newer release extended 64-bit FP-registers to
>> 128-bit vectors), then the numbering scheme has to change. This
On 01/27/2017 07:19 AM, Andreas Arnez wrote:
On Thu, Jan 26 2017, Michael Eager wrote:
I don't understand the assertion that "most significant" can not be
applied to registers. In the case where a register contains a single
value, this appears to be unambiguous. When a register contains
multi
On 01/27/2017 06:49 AM, Andreas Arnez wrote:
On Thu, Jan 26 2017, Michael Eager wrote:
On 01/26/2017 11:17 AM, Andreas Arnez wrote:
Exactly: the current DWARF text*differs* from the usual "defined by the
ABI"-principle when it states for DW_OP_bit_piece: "If the location is a
register, the of
On Thu, Jan 26 2017, Michael Eager wrote:
> I don't understand the assertion that "most significant" can not be
> applied to registers. In the case where a register contains a single
> value, this appears to be unambiguous. When a register contains
> multiple values (some architectures support 2
On Thu, Jan 26 2017, Michael Eager wrote:
> On 01/26/2017 11:17 AM, Andreas Arnez wrote:
>> Exactly: the current DWARF text*differs* from the usual "defined by the
>> ABI"-principle when it states for DW_OP_bit_piece: "If the location is a
>> register, the offset is from the least significant bit
On 01/26/2017 05:19 PM, Cary Coutant wrote:
On the other hand, using bit or byte numbering, or left or right, seem to
depend on who is drawing a diagram and where they start numbering. There
is more consistency in description among big-endian architectures than among
little-endian, but there's c
> On the other hand, using bit or byte numbering, or left or right, seem to
> depend on who is drawing a diagram and where they start numbering. There
> is more consistency in description among big-endian architectures than among
> little-endian, but there's clearly no hard and fast rule.
Funny,
On 01/26/2017 11:17 AM, Andreas Arnez wrote:
Exactly: the current DWARF text*differs* from the usual "defined by the
ABI"-principle when it states for DW_OP_bit_piece: "If the location is a
register, the offset is from the least significant bit end of the
register". This definition limits the A
On 01/26/2017 11:17 AM, Andreas Arnez wrote:
On Wed, Jan 25 2017, Andrew Cagney wrote:
Also, I suggest to avoid the terms "left" and "right", since I
encountered various occasions where they caused more confusion than they
helped. And the term "most significant" can not generally be applied
On 01/26/2017 11:17 AM, Andreas Arnez wrote:
> (Now I wonder how a MIPS big-endian ABI *really* defines DWARF piece
> placement in registers. Do you know?)
These SYSV ABI documents are all...old.
I don't find more recent hardware/ABI documented this way.
Has to be in other sorts of documents.
I
>>> Do you mean that such an ABI would take a DW_OP_piece from a register
>>> according to the "structure parameter passing" rule *whenever* the
>>> composite location describes an object with structure type? But this
>>> would be wrong, wouldn't it? For instance, modern compilers may
>>> optimiz
>>> Also, I suggest to avoid the terms "left" and "right", since I
>>> encountered various occasions where they caused more confusion than they
>>> helped. And the term "most significant" can not generally be applied to
>>> registers either, so in this case I'd prefer something like "located in
>>
On Wed, Jan 25 2017, Andrew Cagney wrote:
The definition of DW_OP_piece differs, though: "[...] the placement of
the piece within that register is defined by the ABI."
>>>
>>> Right.
>>
>> Right, and...? Is it intentional that DW_OP_piece(n)" is not
>> necessarily equivalent to "DW_OP_b
>>> The definition of DW_OP_piece differs, though: "[...] the placement of
>>> the piece within that register is defined by the ABI."
>>
>> Right.
>
> Right, and...? Is it intentional that DW_OP_piece(n)" is not
> necessarily equivalent to "DW_OP_bit_piece(8*n, 0)?
There is no intent.
>> For ins
On Tue, Jan 24 2017, Andrew Cagney wrote:
> On 12 December 2016 at 09:28, Andreas Arnez wrote:
>> On Fri, Dec 09 2016, Adrian Prantl wrote:
>>
>>> Here's my take on this.
>>
>> Thanks!
>>
On Dec 9, 2016, at 11:11 AM, Andreas Arnez
wrote:
[...]
* What is the correct placement ru
On 12 December 2016 at 09:28, Andreas Arnez wrote:
> On Fri, Dec 09 2016, Adrian Prantl wrote:
>
>> Here's my take on this.
>
> Thanks!
>
>>> On Dec 9, 2016, at 11:11 AM, Andreas Arnez wrote:
>>>
>>> Although I've already created public comments for (most of) this,
>>> Michael Eager suggested tha
On Fri, Dec 09 2016, Adrian Prantl wrote:
> Here's my take on this.
Thanks!
>> On Dec 9, 2016, at 11:11 AM, Andreas Arnez wrote:
>>
>> Although I've already created public comments for (most of) this,
>> Michael Eager suggested that I post my questions regarding DWARF pieces
>> on this list (a
Here's my take on this.
> On Dec 9, 2016, at 11:11 AM, Andreas Arnez wrote:
>
> Although I've already created public comments for (most of) this,
> Michael Eager suggested that I post my questions regarding DWARF pieces
> on this list (again).
>
> All of these questions are related to the defi
30 matches
Mail list logo
