<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 1, 2016 at 11:08 AM, Robinson, Paul via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div><br></div><div>Why is this libFuzzer-specific? </div><div><div>We were just [un]lucky to detect the problem early with one of the libFuzzer</div><div>tests that required debug info. </div></div><div><br></div><div>Any tool that needs debug info will suffer from the same problem. No? </div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div></div>