[PATCH] D68945: [DebugInfo] Don't translate dbg.addr and similar intrinsics into indirect DBG_VALUEs

[Adrian Prantl via Phabricator via llvm-commits]

aprantl added a comment.

In D68945#1710656 <https://reviews.llvm.org/D68945#1710656>, @jmorse wrote:

> Adrian wrote:
>
> > Sounds like the problem here is that we don't encode the difference between Memory locations and Register locations in DIExpression and/or DBG_VALUE. I think we currently decide the very late in DwarfExpression.cpp.
>
> Yeah, I've been bitten by this in the past, sometimes adding an extra DW_OP_deref to the end of an expression causes no change to the output DWARF because DwarfExpression.cpp was already guessing the location type ("unknown" -> memory). Particularly awkward is that adding any opcode might implicitly add a deref, if DwarfExpression.cpp starts interpreting the expression as a memory location rather than register location. Unless the expression is already an implicit location, in which case you don't get that extra deref!
>
> > (But we do have DW_OP_stack_value). Maybe we need a DW_OP_LLVM_memory_value, or rename this flag?
>
> IMHO, YMMV, it would be better to head in the other direction and abandon what "kind" of location we have in the compilation stages, because it's a DWARF encoding detail. That would mean adding an opcode to a DIExpression always meant the same thing, with no flags to change their interpretation. Location kinds would have to be decided by DwarfExpression.cpp, something like:




> - All expressions ending in a deref are memory locations
> - Anything else not ending in a deref that performs some kind of computation is an implicit location
> - An empty expression is interpreted as a register location

Those two last examples don't really work: Due to salvageDebugInfo it is perfectly possible to arrive at either a  register or a memory location that ends in `DW_OP_constu 1 DW_OP_plus`

I think we need slightly different tuning knobs. We need to distinguish:

- axis 1: read-only vs. read-write locations Is it safe for the debugger to write to that location to change the variable's value? I think we can only guarantee that for dbg.declare(alloca) at the moment. In DWARF terms this is the difference between `DW_OP_reg0` and `DW_OP_breg0 DW_OP_stack_value`.

- axis 2: SSA-Value/(v)reg vs. memory locations

I need to think harder about this the primary open questions for me are:

- why do we currently add `DW_OP_stack_value` in LLVM IR (which if the two axis does it address)?
- is axis 2 currently implicitly encoded by the kind of value being bound by the DBG_VALUE and would it remove ambiguity to make it explicit? Because of my example above I'm convinced that DW_OP_deref is not a sufficient indicator.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68945