[PATCH] D85018: [WIP][POC][DebugInfo] Support for DW_AT_start_scope for scoped variables

[Sourabh Singh Tomar via Phabricator via llvm-commits]

SouraVX added a comment.

> How does the start scope compare to the location range of the variable, and the scope range of the enclosing scope?

`DW_AT_start_scope` value in contiguous scope case is `offset` from start of the Lex Block(i.e low_pc of enclosing scope).

> In any case - this seems a bit backwards - one of the benefits of start_scope is that we should be able to use singular variable locations in more places because the scope will already be appropriately truncated by the start_scope value.

Indeed, that's the primary problem we want to overcome.

> Also, general question: Why are you implementing this feature? Do you have a debugger that can/will consume this? I hesitate to add features (especially ones with a lot of surface area/additional complexity) that don't have a consumer/customer use case readily available.

The problem is real, reported here also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93844, here pointer is also involved(try with `clang`). We have a downstream `GDB` that solves these sort of problems with the help of `DW_AT_start_scope`. Again up-streaming that is also chicken-egg problem, since no producer(that I'm aware) of produces `DW_AT_start_scope`. And yes (In our downstream `GDB`) `location-list` is not needed, `start_scope` is just enough to show the variable value correctly)

> Also - the spec describes start_scope as being able to contain a range list - for cases where the scope of the variable name is discontiguous. This seems relevant/useful/necessary as well (& would further help reduce the need for location lists on variables if the variable is live for its actual scope - though overall I've more concerns about the scope_start feature creating more expensive IR and DWARF than saving us anything, just that maybe the costs can be mitigated somewhat) & if the feature is important, maybe should be implemented more generally to handle discontiguous scopes.

I started to handle/tackle contiguous scope case first and generalize subsequently. But overall it seems like `debug.value` based representation and capturing info has landed us here. Introducing a new intrinsic(dedicated) *MAY* help to solve the problem, but that will also cost a lot. I'm still looking/exploring the best way to do this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85018