search for: dw_op_reg7

...Memory l-value Indirect $noreg, (plus_uconst, 8, deref, stackval)-> DW_OP_breg7 RSP+8, deref, stackval Stack r-value Direct 0, (plus_uconst, 8, deref, stackval)-> DW_OP_breg7 RSP+8, deref, stackval Stack r-value Direct $noreg, (), -> DW_OP_reg7 RSP Register l-value Direct 0, (), -> DW_OP_breg7 RSP+0 Memory l-value Indirect $noreg, (deref), -> DW_OP_breg7 RSP+0 Memory l-value Indirect 0, (deref),...

...hen inspect the executable with llvm-dwarfdump, I can see that the debug information for fqux clearly lists the location as well. 0x00000918: DW_TAG_subprogram DW_AT_low_pc (0x00000000004207c8) DW_AT_high_pc (0x0000000000420817) DW_AT_frame_base (DW_OP_reg7 RSP) DW_AT_linkage_name ("fqux") DW_AT_name ("fqux") DW_AT_decl_file ("TODO/llvm.hs") DW_AT_decl_line (8) DW_AT_external (true) I suspect this is a problem with the DWARF information as...

...an see that >> the debug information for fqux clearly lists the location as well. >> >> 0x00000918: DW_TAG_subprogram >> DW_AT_low_pc (0x00000000004207c8) >> DW_AT_high_pc (0x0000000000420817) >> DW_AT_frame_base (DW_OP_reg7 RSP) >> DW_AT_linkage_name ("fqux") >> DW_AT_name ("fqux") >> DW_AT_decl_file ("TODO/llvm.hs") >> DW_AT_decl_line (8) >> DW_AT_external (true) >> >>...

> 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

...formation in the binary for "main": <1><a7>: Abbrev Number: 7 (DW_TAG_subprogram) <a8> DW_AT_low_pc : 0x400880 <b0> DW_AT_high_pc : 0xc9 <b4> Unknown AT value: 3fe7: 1 <b4> DW_AT_frame_base : 1 byte block: 57 (DW_OP_reg7 (rsp)) <b6> DW_AT_name : (indirect string, offset: 0xaf): main <ba> DW_AT_decl_file : 1 <bb> DW_AT_decl_line : 16 <bc> DW_AT_prototyped : 1 <bc> DW_AT_type : <0x3f> <c0> DW_AT_external : 1 <c0...

...or fqux clearly lists the location as well. >> >> >> >> 0x00000918: DW_TAG_subprogram >> >> DW_AT_low_pc (0x00000000004207c8) >> >> DW_AT_high_pc (0x0000000000420817) >> >> DW_AT_frame_base (DW_OP_reg7 RSP) >> >> DW_AT_linkage_name ("fqux") >> >> DW_AT_name ("fqux") >> >> DW_AT_decl_file ("TODO/llvm.hs") >> >> DW_AT_decl_line (8) >> >>...

...;this should never be an l-value". Because of this, an expression ending with DW_OP_LLVM_direct 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...

...4-.Ltmp53 # Loc expr size .short .Lset11 .Ltmp53: .byte 80 # DW_OP_reg0 .Ltmp54: .long 0 .long 0 .Ldebug_loc6: .long .Lfunc_begin2 .long .Ltmp44 .Lset12 = .Ltmp56-.Ltmp55 # Loc expr size .short .Lset12 .Ltmp55: .byte 87 # DW_OP_reg7 .Ltmp56: .long 0 .long 0 .Ldebug_loc8: .long .Ltmp41 .long .Ltmp44 .Lset13 = .Ltmp58-.Ltmp57 # Loc expr size .short .Lset13 .Ltmp57: .byte 87 # DW_OP_reg7 .Ltmp58: .long 0 .long 0 .Ldebug_loc10: .long .Ltmp44 .long .Ltmp45 .Lset14 = .Ltmp60-.Ltmp59...

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

...sing DW_OP_LLVM_explicit_pointer. >> >> -------------------------------- >> 0x0000006c: DW_TAG_subprogram >> DW_AT_low_pc (0x00000000004004c0) >> DW_AT_high_pc (0x00000000004004d4) >> DW_AT_frame_base (DW_OP_reg7 RSP) >> DW_AT_call_all_calls (true) >> DW_AT_name ("main") >> DW_AT_decl_file ("explicit_pointer.cc") >> DW_AT_decl_line (14) >> DW_AT_type (0x00000068 &quo...

Let me try to summarize the implementation first. At the moment, there are two branches. 1. When an existing variable is optimized out and that variable is used to get the de-refereced value, pointed to by another pointer/reference variable. Such cases are being addressed using Dwarf expression DW_OP_implicit_pointer as de-referenced value of a pointer can be seen implicitly (using another