On 03/09/2016 02:53 PM, Cary Coutant wrote:
A value which is contained in a register larger than the size of the value should be described by a DW_TAG_base_type. (DWARF 4, Sect. 5.1, bottom of page 75).For a 32-bit float in a 128-bit container, use something like the following: DW_TAG_base_type DW_AT_name "float" DW_AT_encoding DW_ATE_float DW_AT_byte_size 16 DW_AT_bit_size 32 DW_AT_data_bit_offset 0 Note that there is no requirement that the names on base types be unique. There may be more than one with the name "float".Sorry, Michael, but you're just muddying the waters. The data_bit_offset attribute is used only when "the value of an object of the given type does not fully occupy the storage described by a byte size attribute." That is not the case here -- the original question was about a value of a type that does not fully occupy a register, which is a totally different question. We're just not going to expect (nor is it even physically possible in the DWARF representation) that the producer invent a different base type for each possible location where a variable might be stored. Whether it's a single location or a location list is irrelevant to the question, but the possibility that there may be a location list is what exposes the impracticality of your suggestion -- a variable can have only a single type, regardless of how many location list entries it has.
The DWARF did not include a location list. Adrian's DWARF, as written, describes a variable allocated to a register. Apparently permanently, or at least, within the current scope. (I've seen this in embedded code where a variable is assigned to a register.) What was likely intended is a location list which specifies where the variable's *value* may be found, independent of where the variable was allocated. Many optimizations eliminate allocating storage for a variable. When this happens, there isn't a DW_AT_location attribute. If there had been a location list in Adrian's DWARF, the discussion about location lists and how ABIs tell you how to interpret them might have been on point. Without a location list, I don't see the relevance.
I think the rest of us agree that the proper answer is that the ABI defines how a value is stored in a register when the value is smaller than the register, and that clang is producing good DWARF for this example. Whether it's a 32-bit float in a 256-bit xmm register or an 8-bit char in a 64-bit general register, we let the ABI define the representation. In most cases, it's a natural representation that just falls out from the way the instruction set works, and no one really needs to give it much thought (e.g., store the value in the low-order bits of the register, possibly with zero- or sign-extension). In other cases, like some floating-point register files, a value is actually converted to a wider type when loaded into a register. At any rate, we have never attempted to describe those rules in the DWARF, and it would make little sense to try.
An ABI defines loading a value into a register from memory. No one (certainly not me) is trying to define those rules in DWARF.
The source of the original uncertainty about representation of a smaller value in a larger register is probably that the DWARF spec *does* explicitly state, for DW_OP_piece, if "the piece is located in a register, but does not occupy the entire register, the placement of the piece within that register is defined by the ABI." But we make no such similar claim for simple register location descriptions. That led Adrian to wonder if he should be using DW_OP_piece. I think it's an oversight, easily clarified.
There are no DWARF expressions involved here. What does the description of DW_OP_piece have to do with a DWARF description which doesn't use a DWARF expression? -- 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
