[llvm-commits] DBG_VALUE instruction format and generation

[Eric Christopher]

On Sep 3, 2012, at 9:04 AM, Alexey Samsonov <samsonov at google.com> wrote:

> Hi!
> 
> I've got the following questions about DBG_VALUE instruction:
> 1) When I dump this instruction I see the line of the form:
>   DBG_VALUE %EDI, 0, !"a"; line no:47
> for two completely different cases: 
>   * when value of "a" is actually stored in a register %edi  (this should be encoded as "DW_OP_reg5" in DWARF).
>   * when value of "a" is stored in memory at address stored in %edi ("DW_OP_breg5, 0" in DWARF).
> 
> Currently LLVM handles this in favor of first case, and produces wrong debug info for the second case. Can these cases
> actually be distinguished, and if yes, where should I take a look?
> 

Right now it works via the offset mechanism in that if the first operand to the address is a DW_OP_plus we'll turn it into a breg by default. I make no claims that this will work if the offset is zero or that we do the right thing in that case at the moment, but that's how it's currently set up. Basically via the DIVariable creation mechanism.

> 2) This one is more general. I'm trying to make "clang -g" work well with AddressSanitizer instrumentation enabled
> (currently generated debug info for variables is pretty much inconsistent) and need to develop a workflow somehow.
> ASan works with llvm IR, so there are no machine instructions, just llvm.dbg.declare / llvm.dbg.value  intrinsics, which
> are ignored by ASan. How can IR transforms (inserting function calls, basic blocks, etc.) hurt turning llvm.dbg intrinsic into
> a set of DBG_VALUE instructions? What is the best way I can actually see what's going on when we generate machine instructions from IR?

I'm not sure what you mean by hurt? I assume you mean that the pass doesn't look at the debug information right now. As a guess it'll probably want to keep track of the users of an alloca in case it rewrites the access in some way and then update the variable information accordingly. Otherwise I can't think of much that'll hurt the dbg_value/dbg_declare intrinsics if you're leaving the variables alone. Passing -debug will get you information, take a look for dbg_declare and dbg_value in SelectionDAGBuilder.cpp to get an idea of the kind of debug information we're going to drop and the debug output we're going to spew when you do that.

Mostly a vague set of answers but I hope they help. If you've got some specific code I'm more than happy to look at it.

-eric