search for: stack_valu

...t require changes to be made to the flag/DIExpression if the register is RAUWd by a constant or other value, and has a clear definition that doesn't clash with anything in the DWARF spec. Supporting the no-op DIExpression reduction is unlikely to have a huge impact in itself, but having a "stack_value that could be an l-value" nicely rounds out the LLVM representation for debug values. >If we had DW_OP_LLVM_direct: what would be the semantics of > >DIExpression(DW_OP_constu, 4, DW_OP_minus, DW_OP_LLVM_direct) > >versus > >DIExpression(DW_OP_constu, 4, DW_OP_minus) ?...

...;t see how this is a meaningful distinction in LLVM IR. In LLVM IR we only have SSA values. An SSA value could be an alloca, or a gep into an alloca, or spilled onto the stack at the MIR level, in which case the dbg.value should get lowered into a memory location (if it isn't explicitly a DW_OP_stack_value). I think the distinction is still important; even at the IR level, if we have a dbg.value that uses an alloca or something similar, we can still distinguish between "this alloca is the variable's location" versus "this alloca is the variable's value", i.e. the variabl...

...A DWARF expression computes a value; if the available value is a pointer, you add DW_OP_deref to express the pointed-to value. A DWARF location expression computes a location, and adds various operators to express locations that a (value) expression cannot, such as DW_OP_regx. You also have DW_OP_stack_value to say "just kidding, this location expression is a value expression." So, whether we want to start throwing around deref or stack_value or regx (implicit or explicit) really depends on whether we are going to be using value expressions or location expressions. Let's not start mixin...

...ot the address, and we typically use empty DIExpressions. If >>>> the value is ultimately register allocated and the DIExpression is empty, >>>> we will emit a DW_OP_regN location expression. If the value is spilled, we >>>> usually don't need to append DW_OP_stack_value because the location is now >>>> a memory location, which can be described by DW_OP_[f]breg. >>>> >>>> Today, passes that want to add "plus 3" to a DIExpression go out of >>>> their way to add DW_OP_stack_value to the DIExpression because t...

> That makes sense, and I think for "direct" values in your definition it is true that all direct values are r-values. > Why do we need DW_OP_LLVM_direct when we already have DW_OP_LLVM_stack_value? Can you give an example of something that is definitely not a stack value, but direct? The difference in definition is the intention: DW_OP_LLVM_direct means "we'd like this to be an l-value if possible", DW_OP_stack_value means "this should never be an l-value". Because...

> Yeah, because that decision can only be made much later in LLVM in AsmPrinter/DwarfExpression.cpp. > 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. Yes, it might not be clear but that's what I'm trying to say. Out of the non-empty DWARF locations, register and memory locations are l-values, implicit locations are r-values. You can technically use DW_OP_breg in an l-value, but not for register locations. Th...

...> To support that, all existing uses would need no changes to match the >>> DWARF model of registers being implicitly direct values. >>> >>> Code that wanted to describe the register as containing the memory >>> address of the interesting thing would use DW_OP_stack_value to say "this >>> location description that is a register is really an address you should >>> follow to find the value, not a direct value itself"? >>> >>> But code that wanted to describe a variable as being 3 bytes ahead of a >>> pointer in a...

...ble = 2.3341816880621442e-310, v_pointer = 0x2af7ef7e6edc}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}} error = <value optimized out> instance_and_params = (GValue *) 0x0 stack_values = {{g_type = 29300208, data = {{v_int = 29337424, v_uint = 29337424, v_long = 29337424, v_ulong = 29337424, v_int64 = 29337424, v_uint64 = 29337424, v_float = 7.04024007e-38, v_double = 1.4494613335878487e-316, v_pointer = 0x1bfa750}, { v_int = 0, v_uint = 0, v_...

> 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 so...

...bugger begins evaluating a DWARF expression, it assumes that the resulting value will be a pointer to the variable in memory. For a debugger, this makes sense, because debug builds put things in memory and even after optimization many variables must be spilled. Only the special DW_OP_regN and DW_OP_stack_value expression opcodes change the location of the value from memory to register or stack value. LLVM SSA values obviously do not have an address that we can take and they don’t live in registers, so neither the default memory location model nor DW_OP_regN make sense for LLVM’s dbg.value. We could hyp...