[Lldb-commits] [PATCH] D80345: [DwarfExpression] Support entry values for indirect parameters

[Vedant Kumar via Phabricator via lldb-commits]

vsk marked 2 inline comments as done.
vsk added inline comments.


================
Comment at: llvm/test/DebugInfo/MIR/AArch64/dbgcall-site-indirect-param.mir:18
+# CHECK-NEXT: [0x0000000000000000, 0x0000000000000010): DW_OP_breg0 W0+0
+# CHECK-NEXT: [0x0000000000000010, 0x000000000000001c): DW_OP_entry_value(DW_OP_reg0 W0))
+# CHECK-NEXT: DW_AT_name    ("f")
----------------
djtodoro wrote:
> vsk wrote:
> > djtodoro wrote:
> > > I know that the final effect is the same, but should this be `DW_OP_entry_value 2 DW_OP_bregN 0` instead of `DW_OP_entry_value 1 DW_OP_regN`?
> > I'm not sure, the DW_OP_regN description is simply the one that has already been wired up. Is there a reason to prefer 'DW_OP_bregN 0'?
> I was thinking about a more complex entry values where the offset is other than `0`, where by using this way of representation we'll have more complex expression for the same thing.
> If we have expressions as:
> 
> 1) `DW_OP_entry_value 3 DW_OP_bregN M DW_OP_deref DW_OP_stack_value`
> 
> 2) `DW_OP_entry_value 6 DW_OP_entry_value 1 DW_OP_regN DW_OP_plus_uconst M DW_OP_deref DW_OP_stack_value`
> 
> The two expressions have the same effect. They push the value memory location pointed to by value of  register `N` upon entering current subprogram plus `M` had upon entering of the current subprogram.
> 
> This may not be worth of considering now, but we can put a TODO marker in `DwarfExpression`.
> 
> (Sorry If I am asking to much) One quick question:
> 
> Should the `DW_OP_entry_value(DW_OP_reg0 W0))` be an entry value expression with `dw_op_deref` + `dw_op_stack_val`?
> 
These are good questions.

If the indirect parameter offset is not 0, then it seems perfectly fine to apply it outside of the nested entry value expression. However, we don't support emitting entry values in this case. I've added a test to illustrate that.

As for DW_OP_stack_value, I'm not sure it's the right thing to use for locations. It breaks LLDB, fwiw: LLDB doesn't have the type of the object available as it's evaluating a DWARF expression, so when it sees the DW_OP_deref, it can't figure out the size and fails to reconstruct the object.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80345/new/

https://reviews.llvm.org/D80345