<br><br><div class="gmail_quote">On Tue, Sep 4, 2012 at 10:21 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@apple.com" target="_blank">echristo@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Sep 3, 2012, at 9:04 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>
<br>
> Hi!<br>
><br>
> I've got the following questions about DBG_VALUE instruction:<br>
> 1) When I dump this instruction I see the line of the form:<br>
> DBG_VALUE %EDI, 0, !"a"; line no:47<br>
> for two completely different cases:<br>
> * when value of "a" is actually stored in a register %edi (this should be encoded as "DW_OP_reg5" in DWARF).<br>
> * when value of "a" is stored in memory at address stored in %edi ("DW_OP_breg5, 0" in DWARF).<br>
><br>
> Currently LLVM handles this in favor of first case, and produces wrong debug info for the second case. Can these cases<br>
> actually be distinguished, and if yes, where should I take a look?<br>
><br>
<br>
</div>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.<br>
</blockquote><div><br></div><div>This looks weird to me. Either I misunderstand smth, or we should distinguish the cases with zero offset and non-zero offset from address.</div><div>(and use arithmetic instructions in the first case).</div>
<div><br></div><div>My original intent was to apply the following patch to lib/CodeGen/AsmPrinter/AsmPrinter.cpp:</div><div><div>--- AsmPrinter.cpp (revision 163107)</div><div>+++ AsmPrinter.cpp (working copy)</div>
<div>@@ -810,7 +810,9 @@</div><div> // caller might be in the middle of an dwarf expression. We should</div><div> // probably assert that Reg >= 0 once debug info generation is more mature.</div><div> </div><div>- if (int Offset = MLoc.getOffset()) {</div>
<div>+ if (!MLoc.isReg()) {</div><div>+ // Value address is calculated as Reg + Offset.</div><div>+ int Offset = MLoc.getOffset();</div><div> if (Reg < 32) {</div><div> OutStreamer.AddComment(</div><div>
dwarf::OperationEncodingString(dwarf::DW_OP_breg0 + Reg));</div></div><div><br></div><div>As currently AsmPrinter::EmitDwarfRegOp emits DW_OP_reg if offset is zero and DW_OP_breg otherwise.</div><div>This is wrong - MachineLocation(Reg) is a value in register, but MachineLocation(Reg, 0) is a value in memory,</div>
<div>which is calculated at offset 0 from address stored in Reg. If I apply this patch, it breaks stuff :)</div><div><br></div><div>In most cases instruction like</div><div>DBG_VALUE %EDI, 0, !"a"; line no:47</div>
<div>is parsed via the following line:</div><div><div>static DotDebugLocEntry getDebugLocEntry(AsmPrinter *Asm, </div><div><...></div><div> if (MI->getNumOperands() != 3) {</div><div> MachineLocation MLoc = Asm->getDebugValueLocation(MI);</div>
<div> return DotDebugLocEntry(FLabel, SLabel, MLoc, Var);</div><div> }</div><div> if (MI->getOperand(0).isReg() && MI->getOperand(1).isImm()) {</div><div> MachineLocation MLoc;</div><div> MLoc.set(MI->getOperand(0).getReg(), MI->getOperand(1).getImm()); <--------- MachineLocation is set here</div>
<div> return DotDebugLocEntry(FLabel, SLabel, MLoc, Var);</div><div> }</div><div><...><br>in _most_ cases this DBG_VALUE instruction corresponds to the value in register, but in some cases I observe</div></div><div>
it corresponds to the value in memory at zero offset. Hm...</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> 2) This one is more general. I'm trying to make "clang -g" work well with AddressSanitizer instrumentation enabled<br>
> (currently generated debug info for variables is pretty much inconsistent) and need to develop a workflow somehow.<br>
> ASan works with llvm IR, so there are no machine instructions, just llvm.dbg.declare / llvm.dbg.value intrinsics, which<br>
> are ignored by ASan. How can IR transforms (inserting function calls, basic blocks, etc.) hurt turning llvm.dbg intrinsic into<br>
> 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?<br>
<br>
</div>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.<br>
</blockquote><div><br></div><div>Oh, I see the point now - AddressSanitizer pass merges all alloca instructions into one. So we'll likely need to patch dbg_declare instructions accordingly (get the pointer inside the one large allocated chunk that points to the memory corresponding to the original stack variable).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span></blockquote></div><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div><br>