[lldb-dev] DW_OP_deref handling

[Adrian Prantl via lldb-dev]

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

-- adrian