<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hmmm that is a funny sequence. I know the .cfi directives are represented as pseudo-instructions, but they should not be causing us to emit .loc directives.
They have no effect on the .text section so probably they should just be excluded from emitting a location, same as DBG_VALUE is excluded. Also I believe the label there is unnecessary, but that's a separate issue.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regarding "how do we find those problems" this is like "how do we find all the bugs" and what we can do is come up with intelligent approaches to finding where
they are likely to hide. For example, one possibility is to audit all the places that call SetCurrentDebugLocation; my grep through llvm/lib found 43 instances, which is not horrible. We can make sure that the SetInsertPoint/SetCurrentDebugLocation sequence
is correct in all those places. If we can identify components that do depend on the debug line table (like fuzzer and sanitizers) then running a bunch of their tests with –use-unknown-locations turned on by default might also help, after we address the .cfi
thing.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I can look into better handling of .cfi instructions and also do the SetCurrentDebugLocation audit tomorrow.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Kostya Serebryany [mailto:kcc@google.com]
<br>
<b>Sent:</b> Thursday, December 01, 2016 5:01 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] Libfuzzer depending on uninitialized debug info<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Ok... <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The particular instance of the problem can be solved with this patch in my code:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">+ IRB.SetInsertPoint(Ins);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> IRB.SetCurrentDebugLocation(EntryLoc);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- IRB.SetInsertPoint(Ins);<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">(apparently, SetInsertPoint invalidates the previous call to SetCurrentDebugLocation)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But then there is another problem....<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">% cat dummy.c<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">void foo() {}<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">% clang -O -c -gmlt -fsanitize-coverage=func,trace-pc-guard -S dummy.c -o -<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">.LBB0_1:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> .loc 1 1 0 # dummy.c:1:0<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> pushq %rax<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">.Lcfi0:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> .cfi_def_cfa_offset 16<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> movl $.L__sancov_gen_, %edi<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> callq __sanitizer_cov_trace_pc_guard<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">% clang -O -c -gmlt -fsanitize-coverage=func,trace-pc-guard -S dummy.c -mllvm -use-unknown-locations -o -<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">.LBB0_1:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> .loc 1 1 0 is_stmt 0 # dummy.c:1:0<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> pushq %rax<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b> .loc 1 0 0 # :0:0</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">.Lcfi0:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> .cfi_def_cfa_offset 16<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> .loc 1 1 0 is_stmt 1 # dummy.c:1:0<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> movl $.L__sancov_gen_, %edi<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> callq __sanitizer_cov_trace_pc_guard<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Then, when I addr2line the resulting binary some of the instructions get this pesky "<b>.loc 1 0 0</b>" for some reason (did not investigate yet)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I am pretty sure that every particular problem like this can be solved with a simple patch, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">but how do we find those problems before the users get upset enough to file a good bug report? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">--kcc <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Dec 1, 2016 at 4:16 PM, Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">There is already –mllvm –use-unknown-locations which ought to trigger this. Don't need my patch.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="m_4766027178238925610__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></a><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Kostya Serebryany [mailto:<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>]
<br>
<b>Sent:</b> Thursday, December 01, 2016 4:08 PM</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm-dev] Libfuzzer depending on uninitialized debug info<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Thu, Dec 1, 2016 at 3:37 PM, Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">It might be a wider problem than libfuzzer. I did want to raise the problem asap and libfuzzer is
something we know has the problem.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If it came across as "libfuzzer is evil" that was not my intent, sorry!</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">No, no, I did not mean you implied that :) <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Just wanted to make sure everyone understand that this is not libFuzzer-specific. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Looking at lib/Transforms/Instrumentation/SanitizerCoverage.cpp:<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> DebugLoc EntryLoc;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> if (IsEntryBB) {<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> if (auto SP = F.getSubprogram())<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> EntryLoc = DebugLoc::get(SP->getScopeLine(), 0, SP);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> } else {<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> EntryLoc = IP->getDebugLoc();<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> }<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> IRBuilder<> IRB(&*IP);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> IRB.SetCurrentDebugLocation(EntryLoc);<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">So, using this I assumed that the newly generated instructions have proper debug info, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">and so far it worked. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I wonder if you can re-commit your changes under a flag, off-by default, so that everyone interested can play with it? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="m_4766027178238925610_m_-333018136631449"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr</span></a><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Kostya Serebryany [mailto:<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>]
<br>
<b>Sent:</b> Thursday, December 01, 2016 2:53 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm-dev] Libfuzzer depending on uninitialized debug info</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Thu, Dec 1, 2016 at 11:08 AM, Robinson, Paul via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">TL;DR: LibFuzzer appears to depend on debug-info source locations for<br>
whatever IR instrumentation it uses; however, that instrumentation does<br>
not have proper source locations attached to it, leading to potentially<br>
incorrect reporting. The short-term fix is to make sure the debug info<br>
it needs is actually set up; the long-term fix is not to rely on debug<br>
info, because some optimizations will (correctly) erase it.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Why is this libFuzzer-specific? <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We were just [un]lucky to detect the problem early with one of the libFuzzer<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">tests that required debug info. <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Any tool that needs debug info will suffer from the same problem. No? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
The long version:<br>
<br>
When Clang generates IR with debug info, one thing it does is attach a<br>
source location to most IR instructions. This source location (at least<br>
in principle) is carried through optimizations, SelectionDAG, MachineIR,<br>
assembler source, and ultimately ends up in the "line table" in the<br>
object file. The line table describes a mapping from the virtual<br>
addresses of instructions to source locations, which is very useful to<br>
debuggers and other tools.<br>
<br>
Not all IR instructions have a source location attached to them. When<br>
that happens, no specific line-table record is emitted for any machine<br>
instruction produced from that IR instruction. In DWARF, that means you<br>
assume the instruction belongs to the same source location as the<br>
instruction that precedes it in memory.<br>
<br>
This is a problem when the first instruction in a machine-basic-block has<br>
no explicit source location, because it implicitly inherits the source<br>
location of the last instruction of the basic block that precedes it in<br>
memory. That means, the source location is entirely at the mercy of<br>
block layout and other optimizations.<br>
<br>
In effect, the source location for that instruction is UNINITIALIZED.<br>
<br>
In r288283, I committed a patch that explicitly initialized the line<br>
number for some instructions to line 0. The DWARF spec says that line 0<br>
means there is no specific source location for the instruction. Debuggers<br>
and other tools generally respond to this looking *forward* in the<br>
instruction stream to find the *next* instruction with an explicit non-0<br>
location, rather than backward to the *previous* instruction with an<br>
explicit location.<br>
<br>
This caused a libFuzzer test to fail, because it depended on seeing a<br>
real source location for something, and got line 0 instead. This tells<br>
me libFuzzer is depending on an uninitialized source location. Kostya<br>
backed out that patch for me, but we really want to have it for improved<br>
debugger single-stepping behavior.<br>
<br>
I am unclear on what instrumentation the fuzzer is using, although the<br>
instructions for building it suggest it's ASAN instrumentation. Whatever<br>
it is, either the instrumentation should use its own source-location<br>
information scheme, or it should initialize the debug info that it is<br>
depending on.<br>
<br>
Note that debug info is not necessarily reliable in the face of<br>
optimization. If two blocks with different source locations get merged,<br>
most likely the source location will be zeroed (and that's not my patch,<br>
that's optimization-specific behavior). Therefore, I would recommend<br>
that fuzzer/asan/whoever stop relying on debug info for source locations,<br>
if we want all that to work on optimized code.<br>
<br>
In the short term it's probably easier to find places where the<br>
instrumentation is missing debug info, and add it. But that's not going<br>
to be reliable for optimized code.<br>
--paulr<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>