[lldb-dev] DW_OP_deref handling

[Greg Clayton via lldb-dev]

> On Oct 12, 2018, at 9:53 AM, Adrian Prantl <aprantl at apple.com> wrote:
> 
> 
> 
>> On Oct 11, 2018, at 11:16 AM, Greg Clayton via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> 
>> DWARF5 finally added the ability to track what each value means on the expression stack. Prior to DWARF 5, we had no idea what each entry on the expression value stack was (file address, load address (Value::eValueTypeLoadAddress), plain value (Value::eValueTypeScalar). We have tracked this info for a while now, but the DWARF5 spec is much more specific on how things should be treated.
> 
> Greg,
> 
> I'd like to summarize my own understanding of how this works — could you take a look and correct me where I'm wrong?
> 
> - The only way to push a file address onto the DWARF stack is a DW_OP_addr.
> 
> The decision of whether a value pushed onto the DWARF stack is a scalar or a load address depends on the location kind (cf. DWARF 5, section 2.6 "Location Descriptions"):
> - A register location description (DW_OP_reg.*) reads the register contents and pushes a scalar.
> - An implicit location description (.* (DW_OP_implicit_.*|DW_OP_stack_value) yields a scalar after evaluating the expression.
> - A memory location description (anything else, such as DW_OP_breg) yields a load address.
> (- composite locations, like DW_OP_piece are handled according to these rules for each piece)
> 
> Practically speaking, I think this means that a DW_OP_(f)breg always turns into a load address (as it can only appear in an implicit or a memory location), and a DW_OP_reg always. turns into a scalar.
> 
> 
> Is that what LLDB is doing, and if not, could that explain at least some of the failures that Davide is seeing?


Correct!

Summarizing:
- DW_OP_addr == file address
- DW_OP_(f)breg == load address
- DW_OP_reg == scalar
- DW_OP_deref(x) == needs to be fixed to change to scalar, currently leaves it as load addr
- DW_OP_const == scalar (unless DW_OP_piece is used)

The failure Davide is seeing is there is a load address on the stack, and after the deref, it gets pushed the correct value but leaves it as a load addr.

When any expression is done being evaluated, we look at the type of that value that is left at the top of the stack.

If it is a load addr, then we read from memory
if it is a scalar, it is the value itself

Issue Davide is running into is the value is correct, but the type is still load addr incorrectly.

Greg