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 ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
