[llvm-dev] [Debuginfo] Changing llvm.dbg.value and DBG_VALUE to support multiple location operands

Adrian Prantl via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 2 16:36:00 PDT 2020



> On Sep 2, 2020, at 7:01 AM, Tozer, Stephen <stephen.tozer at sony.com> wrote:
> 
>> > I'm not sure this will work as stated here. Indirectness is (mostly) orthogonal to DW_OP_stack_value. DW_OP_stack_value denotes that we reconstructed the value of the variable, but it doesn't exist in the program ("The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known"), for example, a constant value. I think we want something like DW_OP_deref instead, at least for r-values. For l-values (=variables a debugger could write to) we would need to have a discriminator that declares the DBG_VALUE as a memory location (cf. DWARF5 chapter 2.6).
> 
> This is a tricky one. Right now, DIExpressions sort-of mimic DWARF, but with differences that aren't always immediately clear. The reason why I chose DW_OP_stack_value for the direct-value-case instead of using DW_OP_deref for the indirect-value-case is that it is more like actual DWARF: a DWARF expression is either empty, a register, a memory address, or an implicit location.

Yeah, because that decision can only be made much later in LLVM in AsmPrinter/DwarfExpression.cpp.

> The new representation handles each of these faithfully to DWARF, except for being unable to distinguish between the register and memory case for a single register argument. In DWARF, the difference is that a register location uses `DW_OP_reg N`, while any reference to a register's value in any other type of location uses `DW_OP_breg N`. We cannot specify these in LLVM since we only generate these operators at the end; previously, this was the job of the indirectness flag.

In DWARF, DW_OP_reg(x) is a register l-value, all others can either be l-values or r-values depending on whether there is a DW_OP_stack_value/DW_OP_implicit* at the end. 

> 
> Rather than reintroducing a flag just for this purpose however, I instead propose that we treat this as a special (albeit common) case: we can use `DW_OP_LLVM_arg 0, DW_OP_stack_value` with a single register operand.

I think it would be confusing to talk about registers at the LLVM IR / DIExpression level. "SSA-Values"?

> We already reduce the DIExpression to specialized DWARF operators at the point of DWARF emission, for example: `<Register N>, DW_OP_plus_uconst 5` becomes `DW_OP_bregN RSP+5`. If in any case where a stack value expression consists of only a single register it is valid to convert it to a register location,

I don't think that's correct, because a DW_OP_stack_value is an rvalue. But maybe I misunderstood what you were trying to say.

> then this should be a valid transformation; I can't think of any cases where it wouldn't be, since if we get a variable's value directly from a single register then it necessarily exists at that location. The only exception would be where, for one reason or another, we want DWARF to believe that the location is implicit and thus cannot be written to; if such a case exists then it might be suitable grounds to change the behaviour here.
> 
> This does have the potential to cause confusion to a reader unfamiliar with this behaviour, but for a reader examining debug info in enough detail that the removal of DW_OP_stack_value raises an eyebrows, I think simply noting the behaviour in code comments and the documentation would be sufficient.

We should start be defining what DW_OP_stack_value really means in LLVM debug info metadata. I believe it should just mean "r-value".

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200902/2a804738/attachment.html>


More information about the llvm-dev mailing list