[Dwarf-Discuss] Representing the location of smaller values in vector registers

[Robinson, Paul]

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

DW_AT_location provides a location description.  It might be single, it
might be a list.  I guess I'm having a hard time understanding why the form 
of the location description should affect how the type is described.

I'm also not clear where this distinction between the variable's location
and the variable's value's location comes from.  Location descriptions are
specified in terms of the location of the object itself, not the location
of its value.  In a location list, it's not the location of the value that 
moves around, it's the location of the object that moves around.

The only time we talk about location descriptions that produce a value is 
when something has no location at all, and we use DW_OP_implicit_value or 
DW_OP_stack_value, neither of which is in play here.

--paulr