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



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to