From andrew.cagney@gmail.com  Tue Jan 24 19:37:16 2017
From: andrew.cagney@gmail.com (Andrew Cagney)
Date: Tue, 24 Jan 2017 14:37:16 -0500
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3y3zl6x2x.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
Message-ID: <CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>

On 12 December 2016 at 09:28, Andreas Arnez <arnez at linux.vnet.ibm.com> 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 <arnez at linux.vnet.ibm.com> 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 definition of DW_OP_piece and
>>> DW_OP_bit_piece:
>>>
>>> * Is "DW_OP_piece(n)" equivalent to "DW_OP_bit_piece(8*n, 0)"?
>>
>> I would think the answer to this is yes, and if it isn't I would
>> really like to see the counterexample added to the Appendix.
>
> Right, I think clarification would be appropriate either way.
>
> Does anybody vote for "no"?

>>> * What is the correct placement rule for register pieces?  ABI-defined
>>>  or lsb0-ordered?  If lsb0-ordered, how exactly is that order defined
>>>  for non-integer registers?
>>
>> "If the location is a register, the offset is from the least
>> significant bit end of the register."
>> Does this text from the latest draft answer the question?
>> If not, can you give an example where it isn't?
>
> The definition of DW_OP_piece differs, though: "[...] the placement of
> the piece within that register is defined by the ABI."

Right.

For instance, a big-endian ABI (MIPS O32, N32, N64 all come to mind)
may specify that small structures are passed "left aligned" in one or
more registers (i.e., in the high bytes of the register).  This is so
that a word-sized load/store of the register puts the struct at the
correct address.

I'm suggesting non-normative text along the lines of:

/ For instance, so that structure variables passed by register can be
loaded and stored
using register-sized transfers, a big-endian ABI may specify that the
pieces of a structure are "left aligned" within a register (located in
the most significant bytes of the register). /

(for the record, the GCC MIPS compilers I looked at - up to 6.x - all
generated wrong debug info for this case - the never written to memory
structure was described as being in memory)


>>> * Shall DW_OP_bit_piece ignore the offset for stack- and implicit
>>>  values?
>>
>> "If the location is any implicit value or stack value, the
>> DW_OP_bit_piece operation describes a sequence of bits using the least
>> significant bits of that value."
>>
>> No.
>
> Really?  IMHO the wording implies that the least significant bit always
> belongs to the piece.
>
>>> * What is the "least significant bit" of an implicit value?  And is it
>>>  intentional that the placement rule differs between implicit- and
>>>  memory values?
>>
>> I don't know.
>>
>>>
>>> * Some DWARF producers describe a register pair just with a single
>>>  DW_OP_reg<n>.  Can a register piece reach into the next register like
>>>  that as well?
>>
>> You mean for a pair of r1,r2 they would emit only DW_OP_reg1? I don't
>> think this use is supported by the DWARF specification.
>
> OK.  Are there other opinions?

STABS, and early DWARF emitters liked to do this.  For instance, a
64-bit value passed in two adjacent 32-bit registers would only have
the first (even) register specified and then rely on "magic".

DWARF introduced DW_OP_piece et.al. as a way to get away from this so
a modern ABI trying to recommend the old behaviour will likely get
laughed at :-)

BTW a variation of this is still standard.  For instance, something like:

     float f;  // DW_OP_reg st0

While st0 is 80-bit, f is 32-bit, and it is assumed that the consumer
performs an implicit conversion.

>>> * 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 should have been represented
>> with an empty DW_OP_piece.
>
> GCC may describe a long double struct member on x86 as
>
>   DW_OP_regx: 33 (st0); DW_OP_piece: 16
>
> where st0 is only 10 bytes wide.  Is that invalid then?

While something like:
  DW_OP_reg st0; DW_OP_piece 12; DW_OP_piece 4;
might be less ambiguous and safer on a big-endian architecture, the
above does have a reasonable little-endian interpretation.

Since these existing operations are long standing these edge cases
will have already been defined (perhaps implicitly) by the existing
ABIs.

>> If sizeof(obj) < sizeof(reg) the expression is overspecified, but
>> still sound, so I would say yes.
>
> So you'd say the placement rules for DW_OP_reg* and DW_OP_piece shall be
> compatible, both defined by the ABI -- not necessarily lsb0-ordered?
> And the bytes referred to by a "DW_OP_reg*"-location may depend on the
> object's size, but not its type, right?
>
> Note that this wouldn't work well with cases like the "SPU preferred
> slots"; see https://sourceware.org/ml/gdb/2016-01/msg00013.html, section
> 2.2.

It is probably worth pointing out that DWARF is tied to an ABI and the
ABI is, in turn, tied to an underlying hardware architecture (UAE in
PowerPC speak).

For instance, 32-bit ELF x86 binary would be described using 32-bit
ELF x86 DWARF.  If that binary were to be run on a 64-bit machine say,
then the 64-bit hardware designer, ABI designer, 64-bit operating
system and DWARF consumer all get to figure out exactly what that
means and how it works.  For instance, it is the DWARF consumer et.al.
that get to figure out how to map the 32-bit DWARF specified "eax"
onto onto "rax"; not DWARF.

Andrew


From arnez@linux.vnet.ibm.com  Wed Jan 25 18:11:43 2017
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Wed, 25 Jan 2017 19:11:43 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	(Andrew Cagney's message of "Tue, 24 Jan 2017 14:37:16 -0500")
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
Message-ID: <m3k29j2en4.fsf@oc1027705133.ibm.com>

On Tue, Jan 24 2017, Andrew Cagney wrote:

> On 12 December 2016 at 09:28, Andreas Arnez <arnez at linux.vnet.ibm.com> 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 <arnez at linux.vnet.ibm.com> wrote:

[...]

>>>> * What is the correct placement rule for register pieces?  ABI-defined
>>>>  or lsb0-ordered?  If lsb0-ordered, how exactly is that order defined
>>>>  for non-integer registers?
>>>
>>> "If the location is a register, the offset is from the least
>>> significant bit end of the register."
>>> Does this text from the latest draft answer the question?
>>> If not, can you give an example where it isn't?
>>
>> 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)?

> For instance, a big-endian ABI (MIPS O32, N32, N64 all come to mind)
> may specify that small structures are passed "left aligned" in one or
> more registers (i.e., in the high bytes of the register).  This is so
> that a word-sized load/store of the register puts the struct at the
> correct address.
>
> I'm suggesting non-normative text along the lines of:
>
> / For instance, so that structure variables passed by register can be
> loaded and stored
> using register-sized transfers, a big-endian ABI may specify that the
> pieces of a structure are "left aligned" within a register (located in
> the most significant bytes of the register). /

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
optimize a 'short' structure field into a register, then usually
aligning it towards the other end of the register instead.  How should a
DWARF consumer distinguish these cases?

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
the lowest-addressed bytes of the register when stored in memory".

> (for the record, the GCC MIPS compilers I looked at - up to 6.x - all
> generated wrong debug info for this case - the never written to memory
> structure was described as being in memory)

And even if GCC emitted perfect DWARF code, current GDB could not handle
it correctly.  For instance, no ABI-dependent piece placement is
implemented in GDB yet, and the DW_OP_bit_piece offset is always
ignored.  I'm currently working on fixing all the DWARF piece related
bugs in GDB.

[...]

>>>> * Some DWARF producers describe a register pair just with a single
>>>>  DW_OP_reg<n>.  Can a register piece reach into the next register like
>>>>  that as well?
>>>
>>> You mean for a pair of r1,r2 they would emit only DW_OP_reg1? I don't
>>> think this use is supported by the DWARF specification.
>>
>> OK.  Are there other opinions?
>
> STABS, and early DWARF emitters liked to do this.  For instance, a
> 64-bit value passed in two adjacent 32-bit registers would only have
> the first (even) register specified and then rely on "magic".
>
> DWARF introduced DW_OP_piece et.al. as a way to get away from this so
> a modern ABI trying to recommend the old behaviour will likely get
> laughed at :-)

Good, I'd like to eliminate the "adjacent register" logic from GDB's
DWARF piece handling.

> BTW a variation of this is still standard.  For instance, something like:
>
>      float f;  // DW_OP_reg st0
>
> While st0 is 80-bit, f is 32-bit, and it is assumed that the consumer
> performs an implicit conversion.
>
>>>> * 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 should have been represented
>>> with an empty DW_OP_piece.
>>
>> GCC may describe a long double struct member on x86 as
>>
>>   DW_OP_regx: 33 (st0); DW_OP_piece: 16
>>
>> where st0 is only 10 bytes wide.  Is that invalid then?
>
> While something like:
>   DW_OP_reg st0; DW_OP_piece 12; DW_OP_piece 4;
> might be less ambiguous and safer on a big-endian architecture, the
> above does have a reasonable little-endian interpretation.
>
> Since these existing operations are long standing these edge cases
> will have already been defined (perhaps implicitly) by the existing
> ABIs.

Not sure.  GDB's current handling is quirky, however.  The above
probably implies some kind of padding logic, which is missing from
current GDB.  The "adjacent register" logic is used instead, so the
additional 4 bytes are taken from st1.

>>> If sizeof(obj) < sizeof(reg) the expression is overspecified, but
>>> still sound, so I would say yes.
>>
>> So you'd say the placement rules for DW_OP_reg* and DW_OP_piece shall be
>> compatible, both defined by the ABI -- not necessarily lsb0-ordered?
>> And the bytes referred to by a "DW_OP_reg*"-location may depend on the
>> object's size, but not its type, right?
>>
>> Note that this wouldn't work well with cases like the "SPU preferred
>> slots"; see https://sourceware.org/ml/gdb/2016-01/msg00013.html, section
>> 2.2.
>
> It is probably worth pointing out that DWARF is tied to an ABI and the
> ABI is, in turn, tied to an underlying hardware architecture (UAE in
> PowerPC speak).
>
> For instance, 32-bit ELF x86 binary would be described using 32-bit
> ELF x86 DWARF.  If that binary were to be run on a 64-bit machine say,
> then the 64-bit hardware designer, ABI designer, 64-bit operating
> system and DWARF consumer all get to figure out exactly what that
> means and how it works.  For instance, it is the DWARF consumer et.al.
> that get to figure out how to map the 32-bit DWARF specified "eax"
> onto onto "rax"; not DWARF.

Right, and I certainly don't expect DWARF to define that relationship.
Did you get that impression somewhere?

So what about the original question, whether "DW_OP_reg*" followed by
"DW_OP_piece(size of object type)" is always equivalent to omitting the
piece operation?  Yes or no?

Note that this question was originally triggered by a question from
Adrian Prantl regarding DW_OP_reg*:

  http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2016-March/004201.html

To me it seems that DWARF's definition of the placement of the object
addressed by DW_OP_reg* may be lacking.  Currently it just says: "The
object addressed is in register n", whereas the definition of
DW_OP_piece at least states that "the placement of the piece within that
register is defined by the ABI."  IMO, the amount of detail in these two
definitions should be similar, and it would also be helpful to indicate
their relationship, such as addressed by my question above.

--
Andreas



From andrew.cagney@gmail.com  Thu Jan 26 02:06:42 2017
From: andrew.cagney@gmail.com (Andrew Cagney)
Date: Wed, 25 Jan 2017 21:06:42 -0500
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3k29j2en4.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
Message-ID: <CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>

>>> 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 instance, a big-endian ABI (MIPS O32, N32, N64 all come to mind)
>> may specify that small structures are passed "left aligned" in one or
>> more registers (i.e., in the high bytes of the register).  This is so
>> that a word-sized load/store of the register puts the struct at the
>> correct address.
>>
>> I'm suggesting non-normative text along the lines of:
>>
>> / For instance, so that structure variables passed by register can be
>> loaded and stored
>> using register-sized transfers, a big-endian ABI may specify that the
>> pieces of a structure are "left aligned" within a register (located in
>> the most significant bytes of the register). /
>
> 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
> optimize a 'short' structure field into a register, then usually
> aligning it towards the other end of the register instead.  How should a
> DWARF consumer distinguish these cases?

To quote DWARF 3 (where it first appears, dwarf 4 has similar if not
identical text):

DW_OP_bit_piece is used instead of DW_OP_piece when the piece to be
assembled into a value
or assigned to is not byte-sized or is not at the start of a register
or addressable unit of memory.

> 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
> the lowest-addressed bytes of the register when stored in memory".

I've not found this to be true.

>>>> If sizeof(obj) < sizeof(reg) the expression is overspecified, but
>>>> still sound, so I would say yes.
>>>
>>> So you'd say the placement rules for DW_OP_reg* and DW_OP_piece shall be
>>> compatible, both defined by the ABI -- not necessarily lsb0-ordered?
>>> And the bytes referred to by a "DW_OP_reg*"-location may depend on the
>>> object's size, but not its type, right?
>>>
>>> Note that this wouldn't work well with cases like the "SPU preferred
>>> slots"; see https://sourceware.org/ml/gdb/2016-01/msg00013.html, section
>>> 2.2.
>>
>> It is probably worth pointing out that DWARF is tied to an ABI and the
>> ABI is, in turn, tied to an underlying hardware architecture (UAE in
>> PowerPC speak).
>>
>> For instance, 32-bit ELF x86 binary would be described using 32-bit
>> ELF x86 DWARF.  If that binary were to be run on a 64-bit machine say,
>> then the 64-bit hardware designer, ABI designer, 64-bit operating
>> system and DWARF consumer all get to figure out exactly what that
>> means and how it works.  For instance, it is the DWARF consumer et.al.
>> that get to figure out how to map the 32-bit DWARF specified "eax"
>> onto onto "rax"; not DWARF.
>
> Right, and I certainly don't expect DWARF to define that relationship.
> Did you get that impression somewhere?

>From https://sourceware.org/ml/gdb/2016-01/msg00013.html
You refer to precluding "register growth".

> So what about the original question, whether "DW_OP_reg*" followed by
> "DW_OP_piece(size of object type)" is always equivalent to omitting the
> piece operation?  Yes or no?

While this might be true of a specific ABI - I'd not assume that this
is true in general.

> Note that this question was originally triggered by a question from
> Adrian Prantl regarding DW_OP_reg*:
>
>   http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2016-March/004201.html
>
> To me it seems that DWARF's definition of the placement of the object
> addressed by DW_OP_reg* may be lacking.  Currently it just says: "The
> object addressed is in register n", whereas the definition of
> DW_OP_piece at least states that "the placement of the piece within that
> register is defined by the ABI."  IMO, the amount of detail in these two
> definitions should be similar, and it would also be helpful to indicate
> their relationship, such as addressed by my question above.

>From the spec (DWARF 3 is where it first appeared):

Note that the register number represents a DWARF specific mapping of
numbers onto the actual
registers of a given architecture. The mapping should be chosen to
gain optimal density and
should be shared by all users of a given architecture. It is
recommended that this mapping be
defined by the ABI authoring committee for each architecture.

Presumably this mapping onto the given architecture's actual registers
defines (either explicitly or implicitly) the size and other
attributes of the DWARF registers.


From arnez@linux.vnet.ibm.com  Thu Jan 26 19:17:03 2017
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Thu, 26 Jan 2017 20:17:03 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	(Andrew Cagney's message of "Wed, 25 Jan 2017 21:06:42 -0500")
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
Message-ID: <m3a8advdg0.fsf@oc1027705133.ibm.com>

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_bit_piece(8*n, 0)?
>
> There is no intent.

OK, I guess...?  Will some clarifying text be added then?

>>> I'm suggesting non-normative text along the lines of:
>>>
>>> / For instance, so that structure variables passed by register can be
>>> loaded and stored
>>> using register-sized transfers, a big-endian ABI may specify that the
>>> pieces of a structure are "left aligned" within a register (located in
>>> the most significant bytes of the register). /
>>
>> 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
>> optimize a 'short' structure field into a register, then usually
>> aligning it towards the other end of the register instead.  How should a
>> DWARF consumer distinguish these cases?
>
> To quote DWARF 3 (where it first appears, dwarf 4 has similar if not
> identical text):
>
> DW_OP_bit_piece is used instead of DW_OP_piece when the piece to be
> assembled into a value or assigned to is not byte-sized or is not at
> the start of a register or addressable unit of memory.

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 example is flawed.  If that's *not*
what you meant, then the example is probably misleading (at least to
me).  So I suggest to use a different example, or to adjust it so it
actually works.

(Now I wonder how a MIPS big-endian ABI *really* defines DWARF piece
placement in registers.  Do you know?)

>
>> 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
>> the lowest-addressed bytes of the register when stored in memory".
>
> I've not found this to be true.

Really?  I usually refer to lower- and higher-addressed memory units by
"left" and "right", respectively.  However, all diagrams in the Intel 64
and IA-32 architectures have this reversed and show lower addresses
below/right and higher addresses above/left.  Similarly, when referring
to the bytes in a register I'd call the lower- and higher-addressed
bytes (in natural memory representation) "left" and "right",
respectively.  But at least for integer registers some people call the
most significant bytes "left", independently from byte ordering.  I had
a lengthy discussion with Jian Xu, where one of our misunderstandings
was centered around the definition of "left" and "right".  How do you
interpret these terms?

>>> It is probably worth pointing out that DWARF is tied to an ABI and the
>>> ABI is, in turn, tied to an underlying hardware architecture (UAE in
>>> PowerPC speak).
>>>
>>> For instance, 32-bit ELF x86 binary would be described using 32-bit
>>> ELF x86 DWARF.  If that binary were to be run on a 64-bit machine say,
>>> then the 64-bit hardware designer, ABI designer, 64-bit operating
>>> system and DWARF consumer all get to figure out exactly what that
>>> means and how it works.  For instance, it is the DWARF consumer et.al.
>>> that get to figure out how to map the 32-bit DWARF specified "eax"
>>> onto onto "rax"; not DWARF.
>>
>> Right, and I certainly don't expect DWARF to define that relationship.
>> Did you get that impression somewhere?
>
> From https://sourceware.org/ml/gdb/2016-01/msg00013.html
> You refer to precluding "register growth".

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 ABI's freedom such that register
growth can only be anchored at the "least significant bit".

>> So what about the original question, whether "DW_OP_reg*" followed by
>> "DW_OP_piece(size of object type)" is always equivalent to omitting the
>> piece operation?  Yes or no?
>
> While this might be true of a specific ABI - I'd not assume that this
> is true in general.

OK.

>> Note that this question was originally triggered by a question from
>> Adrian Prantl regarding DW_OP_reg*:
>>
>>   http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2016-March/004201.html
>>
>> To me it seems that DWARF's definition of the placement of the object
>> addressed by DW_OP_reg* may be lacking.  Currently it just says: "The
>> object addressed is in register n", whereas the definition of
>> DW_OP_piece at least states that "the placement of the piece within that
>> register is defined by the ABI."  IMO, the amount of detail in these two
>> definitions should be similar, and it would also be helpful to indicate
>> their relationship, such as addressed by my question above.
>
> From the spec (DWARF 3 is where it first appeared):
>
> Note that the register number represents a DWARF specific mapping of
> numbers onto the actual registers of a given architecture. The mapping
> should be chosen to gain optimal density and should be shared by all
> users of a given architecture. It is recommended that this mapping be
> defined by the ABI authoring committee for each architecture.
>
> Presumably this mapping onto the given architecture's actual registers
> defines (either explicitly or implicitly) the size and other
> attributes of the DWARF registers.

Yes, here the DWARF standard gives a useful explanation of the intended
use and interpretation of register numbers.  But it does not give any
hint about placement *within* a register.  I'm just saying that a
similar clarification might be useful for that aspect as well.

Maybe Adrian can comment on this as well, since he brought this up
first?

--
Andreas



From ccoutant@gmail.com  Thu Jan 26 20:37:56 2017
From: ccoutant@gmail.com (Cary Coutant)
Date: Thu, 26 Jan 2017 12:37:56 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3a8advdg0.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com>
Message-ID: <CAJimCsG8NHVr9_==6V1JUgwU4h8ZxPBod+UO5E76HVOfUfxihA@mail.gmail.com>

>>> 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
>>> the lowest-addressed bytes of the register when stored in memory".
>>
>> I've not found this to be true.
>
> Really?  I usually refer to lower- and higher-addressed memory units by
> "left" and "right", respectively.  However, all diagrams in the Intel 64
> and IA-32 architectures have this reversed and show lower addresses
> below/right and higher addresses above/left.  Similarly, when referring
> to the bytes in a register I'd call the lower- and higher-addressed
> bytes (in natural memory representation) "left" and "right",
> respectively.  But at least for integer registers some people call the
> most significant bytes "left", independently from byte ordering.  I had
> a lengthy discussion with Jian Xu, where one of our misunderstandings
> was centered around the definition of "left" and "right".  How do you
> interpret these terms?

I've been guilty of using "left" and "right", and been called out on
it, even when the context was referring simply to bits within a byte
or within a register. I thought they'd be unambiguous in that context,
but they do seem to cause uncertainty, probably for the very reason
that some little-endian diagrams will depict bytes forming a larger
unit from right-to-left.

Instead, I now try to stick with "most-significant" and
"least-significant" when talking about bits within a larger unit, or
bytes within a word, which should always be unambiguous. I really
don't see how those terms could lead to any uncertainty.

When talking about bytes in memory, I try to use "lower address" and
"higher address".

I would, however, avoid referring to bytes within a register. It would
be better to talk about how a byte in memory is placed in the
register, and it should be clear to say something like "a byte is
loaded into the least-significant bits of the register."

-cary


From andrew.cagney@gmail.com  Thu Jan 26 21:36:40 2017
From: andrew.cagney@gmail.com (Andrew Cagney)
Date: Thu, 26 Jan 2017 16:36:40 -0500
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3a8advdg0.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com>
Message-ID: <CAJeAr6sh0TM_Yaound8=OxzTQaa18bnGTsYe_4H+_puuRwnTWw@mail.gmail.com>

>>> 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
>>> optimize a 'short' structure field into a register, then usually
>>> aligning it towards the other end of the register instead.  How should a
>>> DWARF consumer distinguish these cases?
>>
>> To quote DWARF 3 (where it first appears, dwarf 4 has similar if not
>> identical text):
>>
>> DW_OP_bit_piece is used instead of DW_OP_piece when the piece to be
>> assembled into a value or assigned to is not byte-sized or is not at
>> the start of a register or addressable unit of memory.


> 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 example is flawed.  If that's *not*
> what you meant, then the example is probably misleading (at least to
> me).  So I suggest to use a different example, or to adjust it so it
> actually works.

You've lost me here.

>>>> It is probably worth pointing out that DWARF is tied to an ABI and the
>>>> ABI is, in turn, tied to an underlying hardware architecture (UAE in
>>>> PowerPC speak).
>>>>
>>>> For instance, 32-bit ELF x86 binary would be described using 32-bit
>>>> ELF x86 DWARF.  If that binary were to be run on a 64-bit machine say,
>>>> then the 64-bit hardware designer, ABI designer, 64-bit operating
>>>> system and DWARF consumer all get to figure out exactly what that
>>>> means and how it works.  For instance, it is the DWARF consumer et.al.
>>>> that get to figure out how to map the 32-bit DWARF specified "eax"
>>>> onto onto "rax"; not DWARF.
>>>
>>> Right, and I certainly don't expect DWARF to define that relationship.
>>> Did you get that impression somewhere?
>>
>> From https://sourceware.org/ml/gdb/2016-01/msg00013.html
>> You refer to precluding "register growth".
>
> 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 ABI's freedom such that register
> growth can only be anchored at the "least significant bit".

and if a register grows, a new ABI will presumably be defined.


>>> So what about the original question, whether "DW_OP_reg*" followed by
>>> "DW_OP_piece(size of object type)" is always equivalent to omitting the
>>> piece operation?  Yes or no?
>>
>> While this might be true of a specific ABI - I'd not assume that this
>> is true in general.
>
> OK.
>
>>> Note that this question was originally triggered by a question from
>>> Adrian Prantl regarding DW_OP_reg*:
>>>
>>>   http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2016-March/004201.html
>>>
>>> To me it seems that DWARF's definition of the placement of the object
>>> addressed by DW_OP_reg* may be lacking.  Currently it just says: "The
>>> object addressed is in register n", whereas the definition of
>>> DW_OP_piece at least states that "the placement of the piece within that
>>> register is defined by the ABI."  IMO, the amount of detail in these two
>>> definitions should be similar, and it would also be helpful to indicate
>>> their relationship, such as addressed by my question above.
>>
>> From the spec (DWARF 3 is where it first appeared):
>>
>> Note that the register number represents a DWARF specific mapping of
>> numbers onto the actual registers of a given architecture. The mapping
>> should be chosen to gain optimal density and should be shared by all
>> users of a given architecture. It is recommended that this mapping be
>> defined by the ABI authoring committee for each architecture.
>>
>> Presumably this mapping onto the given architecture's actual registers
>> defines (either explicitly or implicitly) the size and other
>> attributes of the DWARF registers.
>
> Yes, here the DWARF standard gives a useful explanation of the intended
> use and interpretation of register numbers.  But it does not give any
> hint about placement *within* a register.  I'm just saying that a
> similar clarification might be useful for that aspect as well.

Hopefully the instruction set architecture manual, that the abi and
DWARF register map are all tied to answers this (or failing that
wikipedia https://en.wikipedia.org/wiki/Extended_precision )


From davea42@linuxmail.org  Thu Jan 26 23:24:09 2017
From: davea42@linuxmail.org (David Anderson)
Date: Thu, 26 Jan 2017 15:24:09 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3a8advdg0.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com>
Message-ID: <f6a5e140-592f-c5ee-c49e-e309f0ae6ac2@linuxmail.org>

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 happen to have the MIPS SYSV ABI and
Motorola 88000 SYSV ABI documents
from 1991 on hand.  Both are big-endian
explicitly in their ABI conformant versions.  (The MIPS
processor can do little-endian too, but that is not an ABI
that is documented and the book says an ABI-conformant
system must support big endian byte ordering).
In 1991 there was no 64bit of either.

Bit offsets for these are explicitly:
  0 at the least significant end
  31 is the most significant end.
On the page bit 31 is at the left end.

Things look the same in registers and memory.
The old ABI never describes the location of floating point fields,
and the other documents that actually described bit offsets for fp
values were...confusing to say the least. For one thing the
ordering of the 32-bit pieces of a 64bit double is not what you
would guess (32bit pieces of the double are swapped).

For x86 the ABI (little-endian) is on line at
http://www.sco.com/developers/devspecs/abi386-4.pdf
which is amazing as sco is long gone.
This document labels itself a draft from
March 19,1997.
Bit fields are show as they appear in an integer register:
meaning as big-endian with most significant bit bit31,
least significant bit is bit zero (just as for MIPS and 88000).
Byte numbers are with least significant byte at byte 0
and most significant byte at byte 3 (as you  would expect).
On the printed page the most significant bit is at the left end.
Floating point formats (as bits or bytes) are not documented here in any
way.


David Anderson
-- 
Ubuntu is an African word meaning 'I can't configure Debian'


From eager@eagercon.com  Fri Jan 27 01:07:44 2017
From: eager@eagercon.com (Michael Eager)
Date: Thu, 26 Jan 2017 17:07:44 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3a8advdg0.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com>
Message-ID: <588A9D60.7060501@eagercon.com>

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 to
>>> registers either, so in this case I'd prefer something like "located in
>>> the lowest-addressed bytes of the register when stored in memory".
>>
>> I've not found this to be true.
>
> Really?  I usually refer to lower- and higher-addressed memory units by
> "left" and "right", respectively.  However, all diagrams in the Intel 64
> and IA-32 architectures have this reversed and show lower addresses
> below/right and higher addresses above/left.  Similarly, when referring
> to the bytes in a register I'd call the lower- and higher-addressed
> bytes (in natural memory representation) "left" and "right",
> respectively.  But at least for integer registers some people call the
> most significant bytes "left", independently from byte ordering.  I had
> a lengthy discussion with Jian Xu, where one of our misunderstandings
> was centered around the definition of "left" and "right".  How do you
> interpret these terms?

The terms "most-significant bit," "least-significant bit," and corresponding
terminology using bytes seems to be unambiguous and well understood.

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.  Registers are not
physical constructs which have an up, down, left, right, front or back.
(At least, in the abstract sense, ignoring physical implementation.)

I've used left or right to refer to register or memory values, usually in
a colloquial fashion, especially when referring to the printed value of a
register or memory value.  Whether left means most-significant or least-
significant, or lower address or higher, depends on how the values are printed.

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 16-bit values in a 32-bit register, for example), then
additional clarification may be needed.  The ABI provides this, usually.  The
situation where a single value is split across two registers is similar.  When
discussing compound values (such as floating point) it is common to say that
the sign bit is in the most-significant bit of the register, without ambiguity.

So, to answer your question "how do I interpret left and right", in a DWARF
context, I don't, since they are not used.  When there is a whiteboard in
front of me, I can point to which ever byte/bit/number is on the left or right.



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


From eager@eagercon.com  Fri Jan 27 01:17:22 2017
From: eager@eagercon.com (Michael Eager)
Date: Thu, 26 Jan 2017 17:17:22 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3a8advdg0.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com>
Message-ID: <588A9FA2.9040002@eagercon.com>

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 ABI's freedom such that register
> growth can only be anchored at the "least significant bit".

That's not the case.  The ABI is free to put a value where ever it wishes
in a register.  The DWARF description will be different, depending on where
the ABI puts the value, indexed from the least-significant bit of the register.
DW_OP_bit_piece is designed explicitly to support this.

I have to admit that I'm unclear exactly what you mean by "register growth".
But if you load a 16-bit value into the most-significant half of a 32-bit register
(is this growing a register?) then you would describe the value in the register
with a length of 16 and an offset of 16.  Same applies for 32-bit values in
64-bit registers.

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


From ccoutant@gmail.com  Fri Jan 27 01:19:43 2017
From: ccoutant@gmail.com (Cary Coutant)
Date: Thu, 26 Jan 2017 17:19:43 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <588A9D60.7060501@eagercon.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9D60.7060501@eagercon.com>
Message-ID: <CAJimCsF63ukaUOtNjNTJTXMKrjPTX-k=NwxLVJXHwJ=e5XXm3w@mail.gmail.com>

> 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, I was going to make the opposite claim: I've seen big-endian
architectures with architecture manuals where bits are numbered left
to right, consistent with bytes in a word, and others where the bits
are numbered right to left, consistent with the power-of-two bit
value, often numbered that way to make the descriptions of shift and
bit-extract instructions internally consistent. On the other hand, I
can't recall ever seeing a little-endian architecture whose manual
numbered bits left to right.

But it's clear that the bit numbering is nothing more than an
arbitrary convention, chosen by the hardware vendor, and we should
never depend on how the bits are numbered by a particular vendor.

-cary


From eager@eagercon.com  Fri Jan 27 02:48:45 2017
From: eager@eagercon.com (Michael Eager)
Date: Thu, 26 Jan 2017 18:48:45 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJimCsF63ukaUOtNjNTJTXMKrjPTX-k=NwxLVJXHwJ=e5XXm3w@mail.gmail.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9D60.7060501@eagercon.com>
	<CAJimCsF63ukaUOtNjNTJTXMKrjPTX-k=NwxLVJXHwJ=e5XXm3w@mail.gmail.com>
Message-ID: <588AB50D.6020601@eagercon.com>

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 clearly no hard and fast rule.
>
> Funny, I was going to make the opposite claim: I've seen big-endian
> architectures with architecture manuals where bits are numbered left
> to right, consistent with bytes in a word, and others where the bits
> are numbered right to left, consistent with the power-of-two bit
> value, often numbered that way to make the descriptions of shift and
> bit-extract instructions internally consistent. On the other hand, I
> can't recall ever seeing a little-endian architecture whose manual
> numbered bits left to right.

PowerPC numbers bits MSB to LSB (left to right).  Conceptually it is
both big- and little-endian, if less so in common practice.

Xilinx MicroBlaze, originally big-endian, numbers bits left to right.
Most MB applications are now little-endian, to be compatible with ARM.

But I'll give you that point, bit numbering is inconsistent in both
big- and litle-endian architectures.


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


From arnez@linux.vnet.ibm.com  Fri Jan 27 14:49:29 2017
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Fri, 27 Jan 2017 15:49:29 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <588A9FA2.9040002@eagercon.com> (Michael Eager's message of "Thu, 
	26 Jan 2017 17:17:22 -0800")
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
Message-ID: <m337g4v9qe.fsf@oc1027705133.ibm.com>

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 end of the
>> register".  This definition limits the ABI's freedom such that register
>> growth can only be anchored at the "least significant bit".
>
> That's not the case.  The ABI is free to put a value where ever it
> wishes in a register.  The DWARF description will be different,
> depending on where the ABI puts the value, indexed from the
> least-significant bit of the register.  DW_OP_bit_piece is designed
> explicitly to support this.
>
> I have to admit that I'm unclear exactly what you mean by "register
> growth".  But if you load a 16-bit value into the most-significant
> half of a 32-bit register (is this growing a register?) then you would
> describe the value in the register with a length of 16 and an offset
> of 16.  Same applies for 32-bit values in 64-bit registers.

By "register growth" I mean those cases where a new ISA release upgrades
a register to a larger size.  This happened when upgrading various
architectures from 32 to 64 bit, when extending floating-point registers
to vector registers, when increasing the size of existing vector
registers, etc.

Now assume that the ABI defines a bit numbering scheme for
DW_OP_bit_piece according to the current DWARF standard's definition,
and that a new version of the ABI supports a new ISA release with
"grown" registers.

If all new bits are "even more significant", then the numbering scheme
from the previous architecture version can be preserved.

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 breaks
compatibility with the debug info in existing programs.  That's the
problem I was trying to outline above.

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, leaving
it to the ABI instead.  The fact that it does in this case also breaks
the link to DW_OP_piece, where the placement *can* be freely defined by
the ABI.

For instance, why does DWARF not define the bit numbering for all kinds
of bit pieces (memory, register, stack values, implicit values) in the
same way?  All objects we can take pieces from have a memory
representation, so we could always define the bit order to be the same
as for memory objects.  This would cause much less special handling for
DWARF producers/consumers.

The only possible reasons I can think of for *not* choosing memory bit
order for register bit pieces are:

(a) To make DW_OP_piece(n) equivalent to DW_OP_bit_piece(8*n, 0).  But
    then we must leave the bit numbering to the ABI instead of trying to
    define a univeral one.

(b) To support "register growth" as described above.  But then we must
    leave the bit numbering to the ABI as well, because DWARF does not
    know the direction of growth.

Is there any advantage of the "bit significance" numbering scheme at
all?  I can't think of any.

--
Andreas



From arnez@linux.vnet.ibm.com  Fri Jan 27 15:19:55 2017
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Fri, 27 Jan 2017 16:19:55 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <588A9D60.7060501@eagercon.com> (Michael Eager's message of "Thu, 
	26 Jan 2017 17:07:44 -0800")
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9D60.7060501@eagercon.com>
Message-ID: <m31svov8bo.fsf@oc1027705133.ibm.com>

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 16-bit values in a
> 32-bit register, for example), then additional clarification may be
> needed.  The ABI provides this, usually.  The situation where a single
> value is split across two registers is similar.  When discussing
> compound values (such as floating point) it is common to say that the
> sign bit is in the most-significant bit of the register, without
> ambiguity.

Hm, can you point to a formal definition?  The usual definition of
"most/least significant bit" assumes that the underlying object is a
single binary integer:

  https://en.wikipedia.org/wiki/Least_significant_bit

And I see how all this still makes sense for registers that can
"naturally" contain full-sized integers.  But not in general.  You
already list some cases that aren't that obvious, and there are many
more.  When you say "the ABI provides this [clarification], usually",
where did you see that?  For instance, when looking at the System V
Application Binary Interface AMD64 Architecture Processor Supplement
Draft Version 0.99.7, I don't see any definition related to DWARF
pieces, nor a clarification of the terms "most/least signficant bit" of
a register.  Did you see something like that in any other ABI?

Maybe I'm too picky, but IMO a standard document should rely on formally
defined terms only.  And "least significant bit", when applied to a
register, is not one of those, I think.

--
Andreas



From eager@eagercon.com  Fri Jan 27 17:40:37 2017
From: eager@eagercon.com (Michael Eager)
Date: Fri, 27 Jan 2017 09:40:37 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m337g4v9qe.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com>
Message-ID: <588B8615.2000001@eagercon.com>

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 offset is from the least significant bit end of the
>>> register".  This definition limits the ABI's freedom such that register
>>> growth can only be anchored at the "least significant bit".
>>
>> That's not the case.  The ABI is free to put a value where ever it
>> wishes in a register.  The DWARF description will be different,
>> depending on where the ABI puts the value, indexed from the
>> least-significant bit of the register.  DW_OP_bit_piece is designed
>> explicitly to support this.
>>
>> I have to admit that I'm unclear exactly what you mean by "register
>> growth".  But if you load a 16-bit value into the most-significant
>> half of a 32-bit register (is this growing a register?) then you would
>> describe the value in the register with a length of 16 and an offset
>> of 16.  Same applies for 32-bit values in 64-bit registers.
>
> By "register growth" I mean those cases where a new ISA release upgrades
> a register to a larger size.  This happened when upgrading various
> architectures from 32 to 64 bit, when extending floating-point registers
> to vector registers, when increasing the size of existing vector
> registers, etc.

The requirements of running a program created for one architecture on
a different (even if similar) architecture is not something which the
DWARF specification defines.

It would seem to me that you need to define a mapping from the old
architecture to the new one, so that you have a clear definition of
what it means to reference a 32-bit register on a 64-bit architecture.
This is out of the scope of DWARF.

> Now assume that the ABI defines a bit numbering scheme for
> DW_OP_bit_piece according to the current DWARF standard's definition,
> and that a new version of the ABI supports a new ISA release with
> "grown" registers.

DWARF only mentions bit numbering in the definition of DW_OP_bit_piece
with regard to values in memory, and it probably should not be doing that.

> If all new bits are "even more significant", then the numbering scheme
> from the previous architecture version can be preserved.
>
> 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 breaks
> compatibility with the debug info in existing programs.  That's the
> problem I was trying to outline above.

You need to emulate the old architecture on the new architecture.  You
cannot assume that DWARF generated for an old architecture will be usable
without interpretation on an arbitrarily different new architecture.

> 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, leaving
> it to the ABI instead.  The fact that it does in this case also breaks
> the link to DW_OP_piece, where the placement *can* be freely defined by
> the ABI.

With the exception I mentioned above, DWARF doesn't mention bit numbering.
DWARF makes no mention of bit numbering with regard to registers, and clearly
doesn't establish a universal register bit numbering scheme.

Different ABIs number register bits in different ways.

> For instance, why does DWARF not define the bit numbering for all kinds
> of bit pieces (memory, register, stack values, implicit values) in the
> same way?  All objects we can take pieces from have a memory
> representation, so we could always define the bit order to be the same
> as for memory objects.  This would cause much less special handling for
> DWARF producers/consumers.

We are discussing adding clarifying text which will make it clear that
register values, implicit values, and stack values are all handled in
the same fashion.

Memory is a more complex issue, because this is where the issues of
little-endian and big-endian come into play, and not all architectures
map values to memory in the same fashion.  The ordering of values in
memory is not the same as in registers.

>
> The only possible reasons I can think of for *not* choosing memory bit
> order for register bit pieces are:
>
> (a) To make DW_OP_piece(n) equivalent to DW_OP_bit_piece(8*n, 0).  But
>      then we must leave the bit numbering to the ABI instead of trying to
>      define a univeral one.

Exactly the opposite appears to be true.  Defining DW_OP_piece in terms
of something defined (or perhaps undefined) in an ABI make it possible to
create situations where this equivalence is false.

>
> (b) To support "register growth" as described above.  But then we must
>      leave the bit numbering to the ABI as well, because DWARF does not
>      know the direction of growth.

DWARF doesn't attempt to specify how a program compiled for one architecture
should be interpreted on a different architecture.

>
> Is there any advantage of the "bit significance" numbering scheme at
> all?  I can't think of any.

DWARF refers to most-significant bit and least significant bit.  These
concepts appear to be well defined and independent of any bit numbering
scheme used by the ABI.

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


From eager@eagercon.com  Fri Jan 27 18:31:35 2017
From: eager@eagercon.com (Michael Eager)
Date: Fri, 27 Jan 2017 10:31:35 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m31svov8bo.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9D60.7060501@eagercon.com>
	<m31svov8bo.fsf@oc1027705133.ibm.com>
Message-ID: <588B9207.3090403@eagercon.com>

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
>> multiple values (some architectures support 2 16-bit values in a
>> 32-bit register, for example), then additional clarification may be
>> needed.  The ABI provides this, usually.  The situation where a single
>> value is split across two registers is similar.  When discussing
>> compound values (such as floating point) it is common to say that the
>> sign bit is in the most-significant bit of the register, without
>> ambiguity.
>
> Hm, can you point to a formal definition?  The usual definition of
> "most/least significant bit" assumes that the underlying object is a
> single binary integer:
>
>    https://en.wikipedia.org/wiki/Least_significant_bit
>
> And I see how all this still makes sense for registers that can
> "naturally" contain full-sized integers.  But not in general.  You
> already list some cases that aren't that obvious, and there are many
> more.  When you say "the ABI provides this [clarification], usually",
> where did you see that?  For instance, when looking at the System V
> Application Binary Interface AMD64 Architecture Processor Supplement
> Draft Version 0.99.7, I don't see any definition related to DWARF
> pieces, nor a clarification of the terms "most/least signficant bit" of
> a register.  Did you see something like that in any other ABI?

There are architectures which support performing arithmetic on multiple
values in a register, say two 16-bit values in a 32-bit register.  The
ISA defines sign bits in each half, and the operations are defined so
that overflow in one half does not affect the other.

>
> Maybe I'm too picky, but IMO a standard document should rely on formally
> defined terms only.  And "least significant bit", when applied to a
> register, is not one of those, I think.

Perhaps we do need a comment that registers are viewed as a sequence
of bits.


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


From arnez@linux.vnet.ibm.com  Fri Jan 27 19:15:54 2017
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Fri, 27 Jan 2017 20:15:54 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <588B8615.2000001@eagercon.com> (Michael Eager's message of "Fri, 
	27 Jan 2017 09:40:37 -0800")
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
Message-ID: <m3tw8ktitx.fsf@oc1027705133.ibm.com>

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 breaks
>> compatibility with the debug info in existing programs.  That's the
>> problem I was trying to outline above.
>
> You need to emulate the old architecture on the new architecture.  You
> cannot assume that DWARF generated for an old architecture will be
> usable without interpretation on an arbitrarily different new
> architecture.

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 valid for old and new binaries to coexist
in the same program?

>> 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, leaving
>> it to the ABI instead.  The fact that it does in this case also breaks
>> the link to DW_OP_piece, where the placement *can* be freely defined by
>> the ABI.
>
> With the exception I mentioned above, DWARF doesn't mention bit
> numbering.  DWARF makes no mention of bit numbering with regard to
> registers, and clearly doesn't establish a universal register bit
> numbering scheme.

It does at least implicitly, when defining the placement rule for
DW_OP_bit_piece.  This definition implies a "universal" bit numbering
scheme that starts with 0 at a register's "least significant bit".

> Different ABIs number register bits in different ways.
>
>> For instance, why does DWARF not define the bit numbering for all kinds
>> of bit pieces (memory, register, stack values, implicit values) in the
>> same way?  All objects we can take pieces from have a memory
>> representation, so we could always define the bit order to be the same
>> as for memory objects.  This would cause much less special handling for
>> DWARF producers/consumers.
>
> We are discussing adding clarifying text which will make it clear that
> register values, implicit values, and stack values are all handled in
> the same fashion.

I don't think that's a good idea.  My point above was just to question
the motivation for the current definition of DW_OP_bit_piece.

> Memory is a more complex issue, because this is where the issues of
> little-endian and big-endian come into play, and not all architectures
> map values to memory in the same fashion.

Curious, I would say memory is the simple case, because the memory bit
order is defined by all ABIs I know of.  Also, DWARF relies on it
anyhow, for instance in the definiton of DW_AT_data_bit_offset.

> The ordering of values in memory is not the same as in registers.

Not sure what you're trying to say with that.

>> The only possible reasons I can think of for *not* choosing memory bit
>> order for register bit pieces are:
>>
>> (a) To make DW_OP_piece(n) equivalent to DW_OP_bit_piece(8*n, 0).  But
>>      then we must leave the bit numbering to the ABI instead of trying to
>>      define a univeral one.
>
> Exactly the opposite appears to be true.  Defining DW_OP_piece in terms
> of something defined (or perhaps undefined) in an ABI make it possible to
> create situations where this equivalence is false.

Maybe you misread my point?  I wrote "register *bit* pieces", i.e., I
was discussing the definition of DW_OP_bit_piece.  I do not question
that the placement rule of DW_OP_piece shall be defined by the ABI.

>> Is there any advantage of the "bit significance" numbering scheme at
>> all?  I can't think of any.
>
> DWARF refers to most-significant bit and least significant bit.  These
> concepts appear to be well defined and independent of any bit numbering
> scheme used by the ABI.

They are not, when applied to registers.  But even if they were, what's
the practical advantage of being independent of the ABI?  We have ABI
dependencies all over the place.

--
Andreas



From arnez@linux.vnet.ibm.com  Fri Jan 27 19:29:59 2017
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Fri, 27 Jan 2017 20:29:59 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJeAr6sh0TM_Yaound8=OxzTQaa18bnGTsYe_4H+_puuRwnTWw@mail.gmail.com>
	(Andrew Cagney's message of "Thu, 26 Jan 2017 16:36:40 -0500")
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com>
	<CAJeAr6sh0TM_Yaound8=OxzTQaa18bnGTsYe_4H+_puuRwnTWw@mail.gmail.com>
Message-ID: <m3sho4ti6g.fsf@oc1027705133.ibm.com>

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 example is flawed.  If that's *not*
>> what you meant, then the example is probably misleading (at least to
>> me).  So I suggest to use a different example, or to adjust it so it
>> actually works.
>
> You've lost me here.

Sorry about that.  Let's try again.  We were discussing your suggestion
for non-normative text:

  / For instance, so that structure variables passed by register can be
  loaded and stored using register-sized transfers, a big-endian ABI may
  specify that the pieces of a structure are "left aligned" within a
  register (located in the most significant bytes of the register). /

I understood that this suggests, for instance, to express the location
of a 12-byte structure variable that was passed via the two 64-bit
registers 4 and 5 as:

  DW_OP_reg4 DW_OP_piece(8) DW_OP_reg5 DW_OP_piece(4)

And that the second piece above would then refer to the *most*
significant bytes of DWARF register 5.

But wouldn't DW_OP_piece(4) be similarly useful for a structure's "int"
field that was optimized into a register?  Only that the piece operation
now refers to the *least* significant bytes of that register, which
doesn't match the above.  So only one of those cases can be covered by
the ABI specification.  Thus the example is flawed, because it appears
to make a case for a useful scenario, but it doesn't.

Or if that was not the point of the example, then the example is
misleading (to me), because then I obviously understood it wrong.

>> Yes, here the DWARF standard gives a useful explanation of the intended
>> use and interpretation of register numbers.  But it does not give any
>> hint about placement *within* a register.  I'm just saying that a
>> similar clarification might be useful for that aspect as well.
>
> Hopefully the instruction set architecture manual, that the abi and
> DWARF register map are all tied to answers this (or failing that
> wikipedia https://en.wikipedia.org/wiki/Extended_precision )

What?  You expect the ISA to define anything related to DWARF?  I've
never seen that.  I also don't understand how the Wikipedia article
about extended precision is related to the DW_OP_reg* operation at all.

I am specifically addressing the text on page 40 in 2.6.1.1.3 "Register
Location Descriptions" in the DWARF5 public review draft:

  1. DW_OP_reg0, DW_OP_reg1, ..., DW_OP_reg31

  The DW_OP_reg<n> operations encode the names of up to 32 registers,
  numbered from 0 through 31, inclusive. The object addressed is in
  register n.

Where I suggest to add something like: "The placement of the object
within the register is defined by the ABI."  There are mainly two
reasons for this:

* There's at least one case where the current definition was
  misinterpreted.  See Adrian Prantl's mail from March last year:
  http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2016-March/004201.html

* This clarification would bring it on the same level of detail as the
  definition of DW_OP_piece.

--
Andreas



From eager@eagercon.com  Fri Jan 27 19:36:03 2017
From: eager@eagercon.com (Michael Eager)
Date: Fri, 27 Jan 2017 11:36:03 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3tw8ktitx.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
	<m3tw8ktitx.fsf@oc1027705133.ibm.com>
Message-ID: <588BA123.4000403@eagercon.com>

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 numbering scheme has to change.  This breaks
>>> compatibility with the debug info in existing programs.  That's the
>>> problem I was trying to outline above.
>>
>> You need to emulate the old architecture on the new architecture.  You
>> cannot assume that DWARF generated for an old architecture will be
>> usable without interpretation on an arbitrarily different new
>> architecture.
>
> 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 valid for old and new binaries to coexist
> in the same program?

I said nothing of the sort.

What I said was that your consumer needs to create a mapping from the old
architecture to the new architecture so that it has a way of interpreting
the DWARF for the old architecture on the new one.

>
>>> 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, leaving
>>> it to the ABI instead.  The fact that it does in this case also breaks
>>> the link to DW_OP_piece, where the placement *can* be freely defined by
>>> the ABI.
>>
>> With the exception I mentioned above, DWARF doesn't mention bit
>> numbering.  DWARF makes no mention of bit numbering with regard to
>> registers, and clearly doesn't establish a universal register bit
>> numbering scheme.
>
> It does at least implicitly, when defining the placement rule for
> DW_OP_bit_piece.  This definition implies a "universal" bit numbering
> scheme that starts with 0 at a register's "least significant bit".

I would recommend that you not try to read between the lines to find
interpretations which you think are present in the DWARF specification
but which are not actually in the text.

>
>> Different ABIs number register bits in different ways.
>>
>>> For instance, why does DWARF not define the bit numbering for all kinds
>>> of bit pieces (memory, register, stack values, implicit values) in the
>>> same way?  All objects we can take pieces from have a memory
>>> representation, so we could always define the bit order to be the same
>>> as for memory objects.  This would cause much less special handling for
>>> DWARF producers/consumers.
>>
>> We are discussing adding clarifying text which will make it clear that
>> register values, implicit values, and stack values are all handled in
>> the same fashion.
>
> I don't think that's a good idea.  My point above was just to question
> the motivation for the current definition of DW_OP_bit_piece.
>
>> Memory is a more complex issue, because this is where the issues of
>> little-endian and big-endian come into play, and not all architectures
>> map values to memory in the same fashion.
>
> Curious, I would say memory is the simple case, because the memory bit
> order is defined by all ABIs I know of.  Also, DWARF relies on it
> anyhow, for instance in the definiton of DW_AT_data_bit_offset.

No, unfortunately, it isn't.

>
>> The ordering of values in memory is not the same as in registers.
>
> Not sure what you're trying to say with that.
>
>>> The only possible reasons I can think of for *not* choosing memory bit
>>> order for register bit pieces are:
>>>
>>> (a) To make DW_OP_piece(n) equivalent to DW_OP_bit_piece(8*n, 0).  But
>>>       then we must leave the bit numbering to the ABI instead of trying to
>>>       define a univeral one.
>>
>> Exactly the opposite appears to be true.  Defining DW_OP_piece in terms
>> of something defined (or perhaps undefined) in an ABI make it possible to
>> create situations where this equivalence is false.
>
> Maybe you misread my point?  I wrote "register *bit* pieces", i.e., I
> was discussing the definition of DW_OP_bit_piece.  I do not question
> that the placement rule of DW_OP_piece shall be defined by the ABI.
>
>>> Is there any advantage of the "bit significance" numbering scheme at
>>> all?  I can't think of any.
>>
>> DWARF refers to most-significant bit and least significant bit.  These
>> concepts appear to be well defined and independent of any bit numbering
>> scheme used by the ABI.
>
> They are not, when applied to registers.  But even if they were, what's
> the practical advantage of being independent of the ABI?  We have ABI
> dependencies all over the place.

DWARF is intended to describe the translation from source to object. Where
possible, we want to make that description explicit, not depending
on information not contained in the DWARF data.


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


From paul.robinson@sony.com  Fri Jan 27 19:40:27 2017
From: paul.robinson@sony.com (Robinson, Paul)
Date: Fri, 27 Jan 2017 19:40:27 +0000
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3tw8ktitx.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
	<m3tw8ktitx.fsf@oc1027705133.ibm.com>
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEAFEEFD454@USCULXMSG08.am.sony.com>



> -----Original Message-----
> From: Dwarf-Discuss [mailto:dwarf-discuss-bounces at 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 questions
> 
> 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 breaks
> >> compatibility with the debug info in existing programs.  That's the
> >> problem I was trying to outline above.
> >
> > You need to emulate the old architecture on the new architecture.  You
> > cannot assume that DWARF generated for an old architecture will be
> > usable without interpretation on an arbitrarily different new
> > architecture.
> 
> 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 valid for old and new binaries to coexist
> in the same program?

I'd expect that the DWARF consumer will understand what the target for the
original executable was, and interpret any DWARF expressions appropriately.

My understanding is that AVX and AVX-512 were considered to expand the
vector registers at the most-significant-bit end, not the LSB end.
https://en.wikipedia.org/wiki/Advanced_Vector_Extensions
This allows the same DWARF register numbers to be reused and counting
bits from the LSB end works regardless of the register width.

I'm not able to find equivalent comparison of the z/Architecture models,
but if they do something similar then it should all Just Work.
--paulr



From ccoutant@gmail.com  Sat Jan 28 00:55:47 2017
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 27 Jan 2017 16:55:47 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
Message-ID: <CAJimCsFxb2g8DV1ebQDP0GnmA4e08HXmjnmfAGY8rKgpYx5PgQ@mail.gmail.com>

>>>> * 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 should have been represented
>>> with an empty DW_OP_piece.
>>
>> GCC may describe a long double struct member on x86 as
>>
>>   DW_OP_regx: 33 (st0); DW_OP_piece: 16
>>
>> where st0 is only 10 bytes wide.  Is that invalid then?

I think we should acknowledge in the text somewhere that there are
some registers where the bits transfer unchanged between memory and
register (e.g., general registers), and others where some translation
happens (e.g., floating-point registers). For the latter, I think it
makes the most sense to think of the x86 80-bit floating point
registers as if they were really 128 bits wide, and the translation is
implicit via knowledge of the architecture (ABI).

-cary


From ccoutant@gmail.com  Sat Jan 28 01:11:52 2017
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 27 Jan 2017 17:11:52 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <m3tw8ktitx.fsf@oc1027705133.ibm.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
	<m3tw8ktitx.fsf@oc1027705133.ibm.com>
Message-ID: <CAJimCsFC1+-78mQojZx8A-b5cct9hhKeGmGy2BTOBF1Fyqww3w@mail.gmail.com>

>>> 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, leaving
>>> it to the ABI instead.  The fact that it does in this case also breaks
>>> the link to DW_OP_piece, where the placement *can* be freely defined by
>>> the ABI.
>>
>> With the exception I mentioned above, DWARF doesn't mention bit
>> numbering.  DWARF makes no mention of bit numbering with regard to
>> registers, and clearly doesn't establish a universal register bit
>> numbering scheme.
>
> It does at least implicitly, when defining the placement rule for
> DW_OP_bit_piece.  This definition implies a "universal" bit numbering
> scheme that starts with 0 at a register's "least significant bit".

This is unfortunate, and we shouldn't be referring to an ABI-defined
bit numbering scheme here.

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 the big- and little-endian examples in D.2.8. We
should never have implied that this bit numbering was meant to match
the bit numbering convention used in the ABI specification.

This is not the only place we use this bit numbering convention -- we
also use it for the DW_AT_data_bit_offset attribute, and it's defined
in Section 5.7, with a reference to the examples in D.2.8.

I think it's also unfortunate that we allowed the offset field for
DW_OP_bit_piece to apply to register values. That's a very different
use for the value, and just adds to the confusion.

-cary


From eager@eagercon.com  Sat Jan 28 01:25:06 2017
From: eager@eagercon.com (Michael Eager)
Date: Fri, 27 Jan 2017 17:25:06 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJimCsFC1+-78mQojZx8A-b5cct9hhKeGmGy2BTOBF1Fyqww3w@mail.gmail.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
	<m3tw8ktitx.fsf@oc1027705133.ibm.com>
	<CAJimCsFC1+-78mQojZx8A-b5cct9hhKeGmGy2BTOBF1Fyqww3w@mail.gmail.com>
Message-ID: <588BF2F2.3090800@eagercon.com>

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 into such low-level detail, leaving
>>>> it to the ABI instead.  The fact that it does in this case also breaks
>>>> the link to DW_OP_piece, where the placement *can* be freely defined by
>>>> the ABI.
>>>
>>> With the exception I mentioned above, DWARF doesn't mention bit
>>> numbering.  DWARF makes no mention of bit numbering with regard to
>>> registers, and clearly doesn't establish a universal register bit
>>> numbering scheme.
>>
>> It does at least implicitly, when defining the placement rule for
>> DW_OP_bit_piece.  This definition implies a "universal" bit numbering
>> scheme that starts with 0 at a register's "least significant bit".
>
> This is unfortunate, and we shouldn't be referring to an ABI-defined
> bit numbering scheme here.

Agreed.

> 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 the big- and little-endian examples in D.2.8. We
> should never have implied that this bit numbering was meant to match
> the bit numbering convention used in the ABI specification.

Unfortunately, that's exactly what DWARF says.

>
> This is not the only place we use this bit numbering convention -- we
> also use it for the DW_AT_data_bit_offset attribute, and it's defined
> in Section 5.7, with a reference to the examples in D.2.8.

Also, not what we want.

> I think it's also unfortunate that we allowed the offset field for
> DW_OP_bit_piece to apply to register values. That's a very different
> use for the value, and just adds to the confusion.

It's the same use when a register contains multiple fields of a struct.


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


From ccoutant@gmail.com  Sat Jan 28 01:32:25 2017
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 27 Jan 2017 17:32:25 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <588BF2F2.3090800@eagercon.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
	<m3tw8ktitx.fsf@oc1027705133.ibm.com>
	<CAJimCsFC1+-78mQojZx8A-b5cct9hhKeGmGy2BTOBF1Fyqww3w@mail.gmail.com>
	<588BF2F2.3090800@eagercon.com>
Message-ID: <CAJimCsGq5OzG6XU36Fh7yexcFod6NC8Bm2w2hSEB-LubbbaYDg@mail.gmail.com>

>> 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 the big- and little-endian examples in D.2.8. We
>> should never have implied that this bit numbering was meant to match
>> the bit numbering convention used in the ABI specification.
>
> Unfortunately, that's exactly what DWARF says.

But it's not what we meant, and we should fix it.

>> This is not the only place we use this bit numbering convention -- we
>> also use it for the DW_AT_data_bit_offset attribute, and it's defined
>> in Section 5.7, with a reference to the examples in D.2.8.
>
> Also, not what we want.

Why is this not what we want? There's really no better way to define a
field's position within a structure.

>> I think it's also unfortunate that we allowed the offset field for
>> DW_OP_bit_piece to apply to register values. That's a very different
>> use for the value, and just adds to the confusion.
>
> It's the same use when a register contains multiple fields of a struct.

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

-cary


From davea42@linuxmail.org  Sat Jan 28 02:36:29 2017
From: davea42@linuxmail.org (David Anderson)
Date: Fri, 27 Jan 2017 18:36:29 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJimCsGq5OzG6XU36Fh7yexcFod6NC8Bm2w2hSEB-LubbbaYDg@mail.gmail.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
	<m3tw8ktitx.fsf@oc1027705133.ibm.com>
	<CAJimCsFC1+-78mQojZx8A-b5cct9hhKeGmGy2BTOBF1Fyqww3w@mail.gmail.com>
	<588BF2F2.3090800@eagercon.com>
	<CAJimCsGq5OzG6XU36Fh7yexcFod6NC8Bm2w2hSEB-LubbbaYDg@mail.gmail.com>
Message-ID: <2354321d-2241-8358-7ee4-ca72b21d4b9f@linuxmail.org>

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 can't configure Debian'


From eager@eagercon.com  Sat Jan 28 07:23:07 2017
From: eager@eagercon.com (Michael Eager)
Date: Fri, 27 Jan 2017 23:23:07 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJimCsGq5OzG6XU36Fh7yexcFod6NC8Bm2w2hSEB-LubbbaYDg@mail.gmail.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
	<m3tw8ktitx.fsf@oc1027705133.ibm.com>
	<CAJimCsFC1+-78mQojZx8A-b5cct9hhKeGmGy2BTOBF1Fyqww3w@mail.gmail.com>
	<588BF2F2.3090800@eagercon.com>
	<CAJimCsGq5OzG6XU36Fh7yexcFod6NC8Bm2w2hSEB-LubbbaYDg@mail.gmail.com>
Message-ID: <588C46DB.5080201@eagercon.com>

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 than a shift and less confusing.

I presume you mean that the value is right-shifted, not left-shifted.
Right-shifting aligns the desired bits at the LSB end.  I think.
And you need to specify that it is masked.  And you probably want to
specify sign extension, or zero fill, but I'm not sure which.  What happens
if the register is a FP reg?  What does it mean to right-shift a floating
point register?

Seems to be way more complicated to me.

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


From eager@eagercon.com  Sat Jan 28 07:36:59 2017
From: eager@eagercon.com (Michael Eager)
Date: Fri, 27 Jan 2017 23:36:59 -0800
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJimCsFxb2g8DV1ebQDP0GnmA4e08HXmjnmfAGY8rKgpYx5PgQ@mail.gmail.com>
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<CAJimCsFxb2g8DV1ebQDP0GnmA4e08HXmjnmfAGY8rKgpYx5PgQ@mail.gmail.com>
Message-ID: <588C4A1B.4050505@eagercon.com>

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 bits in the object that should have been represented
>>>> with an empty DW_OP_piece.
>>>
>>> GCC may describe a long double struct member on x86 as
>>>
>>>    DW_OP_regx: 33 (st0); DW_OP_piece: 16
>>>
>>> where st0 is only 10 bytes wide.  Is that invalid then?
>
> I think we should acknowledge in the text somewhere that there are
> some registers where the bits transfer unchanged between memory and
> register (e.g., general registers), and others where some translation
> happens (e.g., floating-point registers). For the latter, I think it
> makes the most sense to think of the x86 80-bit floating point
> registers as if they were really 128 bits wide, and the translation is
> implicit via knowledge of the architecture (ABI).

We are talking about the DWARF Standard, aren't we, not the X86 ISA?

The X86 ISA specification should describe the result of executing an
instruction which transfers a value between a register and memory.

If you want to say something in DWARF like "values in a register may be
represented unchanged or differently from the value in memory" that may be
true and completely uninformative.  And I'm not sure that you can define
what "unchanged" means.  Little-endian and big-endian store the bytes
of a register in different orders.  Which is unchanged?

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


From arnez@linux.vnet.ibm.com  Mon Jan 30 09:49:08 2017
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Mon, 30 Jan 2017 10:49:08 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEAFEEFD454@USCULXMSG08.am.sony.com>
	(Paul Robinson's message of "Fri, 27 Jan 2017 19:40:27 +0000")
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
	<m3tw8ktitx.fsf@oc1027705133.ibm.com>
	<E3B07FDB86BFF041819DC057DEED8FEAFEEFD454@USCULXMSG08.am.sony.com>
Message-ID: <m360kwq3mz.fsf@oc1027705133.ibm.com>

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 valid for old and new binaries to coexist
>> in the same program?
>
> I'd expect that the DWARF consumer will understand what the target for
> the original executable was, and interpret any DWARF expressions
> appropriately.
>
> My understanding is that AVX and AVX-512 were considered to expand the
> vector registers at the most-significant-bit end, not the LSB end.
> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions
> This allows the same DWARF register numbers to be reused and counting
> bits from the LSB end works regardless of the register width.

Correct.  So DWARF happens to support this scenario without any
translation.  That's what I mean by *supporting* "register growth".

> I'm not able to find equivalent comparison of the z/Architecture
> models, but if they do something similar then it should all Just Work.

And that's the point: the first 16 vector registers of z13 are
expansions of the existing FP registers at the *LSB* end.  So,
unfortunately, it does not just work.

--
Andreas



From arnez@linux.vnet.ibm.com  Mon Jan 30 14:00:26 2017
From: arnez@linux.vnet.ibm.com (Andreas Arnez)
Date: Mon, 30 Jan 2017 15:00:26 +0100
Subject: [Dwarf-Discuss] DWARF piece questions
In-Reply-To: <CAJimCsGq5OzG6XU36Fh7yexcFod6NC8Bm2w2hSEB-LubbbaYDg@mail.gmail.com>
	(Cary Coutant's message of "Fri, 27 Jan 2017 17:32:25 -0800")
References: <m3r35gq5nt.fsf@oc1027705133.ibm.com>
	<93E7BC75-F70D-4C16-B036-2EBC2D93B2CC@apple.com>
	<m3y3zl6x2x.fsf@oc1027705133.ibm.com>
	<CAJeAr6tCv5GkZjWUrgiS_9TpLuGXjX7xyMQxT43VdiZqv7A-ZQ@mail.gmail.com>
	<m3k29j2en4.fsf@oc1027705133.ibm.com>
	<CAJeAr6v1yzeJXSdfxGYdkZK_GBrV0UUdOXgE1H6k=MG34vmomw@mail.gmail.com>
	<m3a8advdg0.fsf@oc1027705133.ibm.com> <588A9FA2.9040002@eagercon.com>
	<m337g4v9qe.fsf@oc1027705133.ibm.com> <588B8615.2000001@eagercon.com>
	<m3tw8ktitx.fsf@oc1027705133.ibm.com>
	<CAJimCsFC1+-78mQojZx8A-b5cct9hhKeGmGy2BTOBF1Fyqww3w@mail.gmail.com>
	<588BF2F2.3090800@eagercon.com>
	<CAJimCsGq5OzG6XU36Fh7yexcFod6NC8Bm2w2hSEB-LubbbaYDg@mail.gmail.com>
Message-ID: <m3y3xsodfp.fsf@oc1027705133.ibm.com>

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 fields plus internal padding, as
>>> demonstrated in the big- and little-endian examples in D.2.8. We
>>> should never have implied that this bit numbering was meant to match
>>> the bit numbering convention used in the ABI specification.
>>
>> Unfortunately, that's exactly what DWARF says.
>
> But it's not what we meant, and we should fix it.
>
>>> This is not the only place we use this bit numbering convention -- we
>>> also use it for the DW_AT_data_bit_offset attribute, and it's defined
>>> in Section 5.7, with a reference to the examples in D.2.8.
>>
>> Also, not what we want.
>
> Why is this not what we want? There's really no better way to define a
> field's position within a structure.

I must admit, I have trouble following this discussion...

Maybe we can get more concrete?  Let's say a DWARF consumer is requested
to print a variable that has a composite DW_AT_location.  First it
concatenates the individual pieces into a destination buffer, to
represent the variable's value as if it were located in the program's
memory.  Then it uses its usual from-memory print function for the given
variable's type.

In that scenario, suppose that the DWARF consumer has already copied the
first p-1 pieces, whose bit sizes add up to k bits.  Next is the p'th
piece, which is described as a DW_OP_bit_piece (say) with offset m and
bit size n.  Now the DWARF consumer copies the bits for this piece to
the destination buffer with this pseudo-code:

    FOR i IN (0 .. n-1)
      COPY source_bit(m + i) TO dest_bit(k + i)

where source_bit() and dest_bit() somehow map an integer to a bit in the
underlying source- and destination object, respectively.

So, with this scenario in mind, I thought we were discussing how to
define the source_bit() mapping for the various flavors of underlying
objects (memory, register, stack value, indirect value), right?

And is it correct that for memory pieces source_bit() provides the same
relative mapping as dest_bit()?

And that dest_bit(j) addresses the same bit as DW_AT_data_bit_offset(j)?

And that DW_AT_data_bit_offset(j) addresses the same bit as the bit
field 'x' in the following C structure?

    struct bit_j
      {
        unsigned char : 1;
        [ ... ] /* (j-1) copies of the line above */
        unsigned char x : 1;
      };

--
Andreas



