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

[Djordje Todorovic via Phabricator via llvm-commits]

djtodoro accepted this revision.
djtodoro added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!



================
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")
----------------
vsk wrote:
> 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.
>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.
Thanks!


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

Ah, sure.. The DW_OP_stack_value should be used for describing actual values rather than locations, so thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80345