[llvm-dev] [RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR

[Djordje Todorovic via llvm-dev]

Hi all,

The debug entry values feature introduces new DWARF symbols (tags, attributes, operations) on caller (call site) as well as on callee side; and the intention is to improve debugging user experience by using the functionality (especially in “optimized” code by turning “<optimized_out>” values into real values). The call site information includes info about call itself (described with DW_TAG_call_site) with corresponding children representing function arguments at the call site (described with DW_TAG_call_site_params). The most interesting DWARF attribute for us (here) is DW_AT_call_value which contains a DWARF expression which represents a value of the parameter at the time of the call. For the context of this RFC, more relevant part of the feature is the callee side, and it refers to new DWARF operation - DW_OP_entry_value, used to indicate that in some situations we can use parameter’s entry value as a real value in the current frame. It relies on the call-site info provided, and the more DW_AT_call_value generated, the more debug location inputs using DW_OP_entry_value will be turned into real values.

Current implementation in LLVM

Currently in LLVM, we generate the DW_OP_entry_values *only* for unmodified parameters during the LiveDebugValues pass, for the places where the Code Generation truncated live range of the parameters. The potential of the functionality goes beyond this, and it means we should be able to use the entry values even for modified parameters iff the modification could be expressed in terms of its entry value. In addition, there are cases where we can express values of local variables in terms of some parameter’s entry-values (e.g. int local = param + 2;).

Proposal

The idea of this RFC is to introduce an idea/discussion of using the DW_OP_entry_value not only at the end of LLVM pipeline (within LiveDebugValues). There are cases it could be useful at IR level; i.e. for unused arguments (please take a look into https://reviews.llvm.org/D85012); I believe there are a lot of cases where an IR pass drops/cuts variable’s debug value info where an entry value can fall back on as a backup location. There could be multiple ways of implementation, but in general, we need to extend metadata describing the debug value to support/refer to entry value/backup value as well (and when primary location is lost, the value with DW_OP_entry_value becomes the primary one). One way could be extending of llvm.dbg.value with an additional operand as following:

               llvm.dbg.value(…, DIEntryValExpression(DW_OP_uconst, 5)) // DIEntryValExpression implicitly contains DW_OP_entry_value operation

The bottom line is that the production of call-site side of the feature stays the same, but LLVM will have more freedom to generate more of DW_OP_entry_values operation on the callee side.

Any thoughts on this?

Best regards,
Djordje
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/266dde12/attachment.html>