search for: dw_op_breg7

...sions are different however, because we don't have DW_OP_reg or DW_OP_breg: we simply refer to the register and use context to determine which it should be. The best example of this is from this example[0], expanded on here with the location type: $noreg, (plus_uconst, 8), -> DW_OP_breg7 RSP+8) Memory l-value Indirect 0, (plus_uconst, 8), -> DW_OP_breg7 RSP+8) Memory l-value Indirect $noreg, (plus_uconst, 8, stackval), -> DW_OP_breg7 RSP+8, stackval Stack r-value Direct 0, (plus_uconst,...

> Can you elaborate what "direct" means? I'm having trouble understanding what the opposite (a non-exact value) would be. Apologies, "exact" was a misleading/incorrect term. By direct, I mean that the expression computes the value of the variable, as opposed to its memory address, or the value that it points to. Within LLVM, where we don't have DW_OP_reg/DW_OP_breg

...can be emitted as an l-value in any case where the value of the preceding expression is equal to an l-value. So for example: DBG_VALUE $rsp, !"x", !DIExpression(DW_OP_LLVM_direct) => DW_OP_reg7 RSP DBG_VALUE $rsp, !"x", !DIExpression(DW_OP_deref, DW_OP_LLVM_direct) => DW_OP_breg7 RSP+0 DBG_VALUE $rsp, !"x", !DIExpression(DW_OP_plus_uconst, 4, DW_OP_LLVM_direct) => DW_OP_breg7 RSP+4, DW_OP_stack_value Your point about the semantics of variable assignments in the debugger is useful, that clears up my misunderstandings. I believe that even with that in mind, LL...

...ll register locations and some implicit locations, we can safely say that any expression that isn't _direct, implicit, or empty will be a memory location. So for the first expression we would check to see if it could be emitted as a register location, and when that fails we emit a stack value: DW_OP_breg7 RSP+0, DW_OP_constu 4, DW_OP_minus, DW_OP_stack_value Since the second expression is not LLVM_direct, stack_value, implicit_ptr, or any other explicitly declared location type, then it must be a memory location, so we emit: DW_OP_breg7 RSP+0, DW_OP_constu 4, DW_OP_minus -------------- next part -...

Hi Adrian & Stephen, One thought here: But — not all memory locations are l-values. If we have a DWARF location list for variable "x" which points to a memory address for the first n instructions and the switches to a constant for the remainder of the scope, the memory address is not guaranteed to be an l-value, because writing the the memory address cannot affect the later part of

...ecessary. This will also allow us to fix debug info for px in this example: void __attribute__((optnone, noinline)) usevar(int *x) {} int main(int argc, char **argv) { int x = 42; int *px = &x; usevar(&x); if (argc) usevar(px); } Today, we emit a location for px like `DW_OP_breg7 RSP+12`, which gives it the incorrect value 42. This is because our DBG_VALUE instruction for px’s location uses a frame index, which we assume is in memory. This is not the case, px is not in memory, it’s value is a stack object pointer. Please reply if you have any thoughts on this proposal. Adr...

...ecessary. This will also allow us to fix debug info for px in this example: void __attribute__((optnone, noinline)) usevar(int *x) {} int main(int argc, char **argv) { int x = 42; int *px = &x; usevar(&x); if (argc) usevar(px); } Today, we emit a location for px like `DW_OP_breg7 RSP+12`, which gives it the incorrect value 42. This is because our DBG_VALUE instruction for px’s location uses a frame index, which we assume is in memory. This is not the case, px is not in memory, it’s value is a stack object pointer. Please reply if you have any thoughts on this proposal. Adr...

...ecessary. This will also allow us to fix debug info for px in this example: void __attribute__((optnone, noinline)) usevar(int *x) {} int main(int argc, char **argv) { int x = 42; int *px = &x; usevar(&x); if (argc) usevar(px); } Today, we emit a location for px like `DW_OP_breg7 RSP+12`, which gives it the incorrect value 42. This is because our DBG_VALUE instruction for px’s location uses a frame index, which we assume is in memory. This is not the case, px is not in memory, it’s value is a stack object pointer. Please reply if you have any thoughts on this proposal. Adr...