search for: dw_op_

...9007== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==29007== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==29007== Command: /usr/local/lib64/R-2.15.0-vg2/lib64/R/bin/exec/R --vanilla ==29007== --29007-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a valgrind: m_debuginfo/readdwarf.c:2292 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. ==29007== at 0x3802B1F7: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) sched status: running_tid=0 Note: see also the FAQ i...

...wrote: > On Tue, Sep 5, 2017 at 1:00 PM Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 hypothetically >> repurpose DW_OP_stack_value to indicate that the SSA value passed to >> llvm.dbg.value *is* the variable’s value, and if the expression lacks >> DW_OP_stack_value, it must be a the address of the value. However, that...

...gt; >> On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> I guess you described this already, but talking it through for >>> myself/maybe others will find this useful: >>> >>> So since we don't have DW_OP_regN for LLVM registers, we could sort of >>> assume the implicit first value on the stack is a pseudo-OP_regN of the >>> LLVM SSA register. >>> >> >> Yep, that's how we use DIExpressions in both IR and MIR: The LHS of the >> dbg.value and DBG_VALUE i...

...t consistent. In LLVM IR today, the SSA value of the dbg.value *is* the interesting >>>> value, it is not 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 "pl...

...e, it accepts that information as more reliable and discards all DBG_VALUE instructions associated with that variable. So, we need something we can mix. We need a way to say, the variable lives in memory *at this program point*, and it might live somewhere else later on. I propose that we introduce DW_OP_LLVM_memory for this purpose, and then we transition from dbg.declare to dbg.value+DW_OP_LLVM_memory. Initially I believed that DW_OP_deref was the way to say this with existing DWARF expression opcodes, but I implemented that in https://reviews.llvm.org/D37311 and learned more about how DWARF expr...