[Dwarf-Discuss] DWARF piece questions
andrew.cagney at gmail.com
Wed Jan 25 18:06:42 PST 2017
>>> The definition of DW_OP_piece differs, though: "[...] the placement of
>>> the piece within that register is defined by the ABI."
> 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
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
>> 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?
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*:
> 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.
More information about the Dwarf-Discuss