[Dwarf-discuss] Constant expressions in locations lists

[Ron Brender]

Cary Coutant wrote:
> Jim Blandy wrote:
>> I think an expression operator might be a nice way to solve this, but
>> DW_OP_addressof has some difficulties.  The values on the stack are
>> always address-sized, so you would have difficulty producing constant
>> values of floating-point, very large integer, or structure types.
>>
>> Perhaps an operator DW_OP_constant, followed by an LEB128 size,
>> followed by that many bytes of data in target form, permitted to
>> appear wherever a location expression may occur.
> 
> and Daniel Berlin wrote:
>> Why not just a DW_OP_constant_value?
> 
> Yes, this is probably better.
> 
> I did consider that approach, but it seemed potentially confusing,  
> given that it would be quite different from the existing DW_OP_const*  
> and DW_OP_lit* operators. Nevertheless, Jim's point about large  
> values is a good one, and I think it overrides my concern about  
> confusion. If this new operator were introduced in Section 2.5.1 (or  
> in a new section immediately following), it could be made clear that  
> this operator provides a constant value as opposed to a constant to  
> be used for address computation. The rules for its use, I think,  
> could be exactly the same as those for DW_OP_reg*, and could be used  
> as part of a DW_OP_piece construction as well.
>... 

DW_OP_constant_value feels like it is on the right track. Other names 
that might be less confusing vis-a-vis the current DW_OP_const* 
operators might be DW_OP_immediate_value or DW_OP_known_value or 
DW_OP_implicit_value (now just where did that Thesaurus go...). I like 
the name DW_OP_implicit_value personally because it does sort'a suggest 
that there is no specific place where that value can be found (or replaced).

I suggest that the operand begin with a ULEB128 (not LEB128) size which 
is then followed by the given number of bytes of data.

As Cary suggests, this operator functions just like the DW_OP_reg* 
operators; in particular, it does not affect the expression stack and 
must occur alone except as the first operand of a piece expression.

A variation might be a DW_OP_die operator whose single operand would be 
a 4 or 8 byte offset to a DIE in the .debug_info section. Target kinds 
of DIE that make sense are probably only

   . DW_TAG_constant [Sec 4.1] that has a DW_AT_const_value attribute
     (and no DW_AT_location), or

   . DW_AT_enumerator [Sec 5.8]

The advantage of DW_OP_die over DW_OP_implicit_value comes for large 
(aggregate) values which can thus be shared among multiple location 
lists rather than repeated in situ. I suspect, however, that implicit 
values will much more often be small rather than large so I actually 
lean toward the original DW_OP_implicit_value formulation.

Ron