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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
