[Dwarf-Discuss] DWARF piece questions

[Michael Eager]

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