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