search for: dw_op_consts

...t i32 %c.0, !dbg !22 } The value of the variable c when on the return statement is always incorrectly reported as being the value 2. The generated DWARF location list for the variable c looks something like (the offset 00000038 is beyond the end of the function): 00000013 00000004 00000024 (DW_OP_consts: 1; DW_OP_stack_value) 00000020 00000024 00000038 (DW_OP_consts: 2; DW_OP_stack_value) I know what is wrong, I thought! After the phi instruction there should be an @llvm.dbg.value call which describes the variable c as having the value returned by the phi, so I manually altered the IR to t...

...of the variable c when on the return statement is always > incorrectly reported as being the value 2. The generated DWARF location > list for the variable c looks something like (the offset 00000038 is beyond > the end of the function): > > > > 00000013 00000004 00000024 (DW_OP_consts: 1; DW_OP_stack_value) > > 00000020 00000024 00000038 (DW_OP_consts: 2; DW_OP_stack_value) > > > I know what is wrong, I thought! After the phi instruction there should > be an @llvm.dbg.value call which describes the variable c as having the > value returned by the phi,...

...gt;> DW_AT_type (0x00000062 "int&") >> >> 0x00000088: DW_TAG_variable >> DW_AT_location (indexed (0x2) loclist = >> 0x0000002e: >> [0x000000000040049a, 0x00000000004004a0): >> DW_OP_consts +9, DW_OP_stack_value) >> DW_AT_name ("res") >> DW_AT_decl_file ("ref.cc") >> DW_AT_decl_line (12) >> DW_AT_type (0x00000037 "int") >> >> 0x000...

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