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
