> On Oct 11, 2018, at 11:16 AM, Greg Clayton via lldb-dev > <lldb-dev@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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
