[Dwarf-Discuss] data-location containing "DW_OP_push_object_address / DW_OP_deref" if the variable could be in memory or register

[Martin]

On 27/10/2021 17:34, John DelSignore wrote:

> One of the key concepts in the extensions, which I think addresses the 
> problem you described, is to make locations (memory, register, 
> composite, implicit, and undefined) first-class objects that can be 
> pushed onto the DWARF evaluation stack.

Certainly relates to the problem. I would have just called them all 
"address" in different address spaces.

Register already have ordinal/numeric "addresses". They just do not 
point to memory.

But yes, given its a "location expression" the word "location is better.

Dwarf5 itself introduces this (as I pointed out) in its examples
> There is an example that gives some clue what should happen, if a
> DW_AT_location returns a value like this.
> Page 291 (Dwarf 5)
>> DW_OP_lit1 DW_OP_stack_value DW_OP_piece 4 DW_OP_breg3 0 DW_OP_breg4 0
>> 1110 DW_OP_plus DW_OP_stack_value DW_OP_piece 4
>> The object value is found in an anonymous (virtual) location

However, it does not allow such a location to be DW_OP_deref.

And that is the real pity. Because a member or data location, now only 
works, if the new address is stored in memory.
But if a register contains a pointer, then the location of that register 
can not be dereferenced to the memory location described by that pointer.

That is, to be exact: There is no single expression that can take a 
memory OR register location, and deref them.

And at minute 3:02:05 they add exactly that extension:
Allow DW_OP_deref to take any location. And make the content of that 
location an address pointing to memory.



> making a location the /result/ of an evaluation, locations can be 
> pushed, popped, and operated on just like addresses and values in the 
> current model.

If locations can not get on the stack at all currently then what does 
the following do?

- variable DW_AT_Location: DW_OP_reg1
- type DW_AT_data_location:  DW_OP_push_object_address

What is now on the stack of the DW_AT_data_location?
I would have thought it is the register-location.
Meaning that the DW_AT_data_location can do no useful operation at all.

And the same applies for DW_OP_piece appearing in DW_TAG_location, which 
is a virtual location and can not be processed into anything.


The problem is, that you need a different expression in 
DW_AT_data_location, depending if a pointer is stored in memory or register.
Changing the DW_at_location, to return the register value, instead of 
location, will not work either.

-----------------
Hoping that more debuggers adapt to the new DW_OP_deref I can use 
exactly that. And it will work fine.
But then maybe it should be made part of the DWARF spec?


Personally I think DW_AT_location should always return a location.
E.g. DW_OP_stack_value should be a virtual location. (afaik that would 
not even break anything)

Btw the DWARF5 says "DW_OP_stack_value operation" but contradicts this 
in the examples.

If locations are used like this, then it needs to be defined which 
operations can deal which with type of location.

E.g. DW_OP_deref would always take the value at the location, and treat 
it as an address (memory location).

Other ops can be decided when/if needed.