<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">FYI, if we do end up deciding that asan
needs a stronger guarantee than debug info can provide, we have
another mechanism in tree which is available for this purpose.
Operand bundles can be associated with a callsite today to provide
a guaranteed side table of value locations at runtime. We use the
"deopt" bundle type for exactly this purpose and it's explicitly
part of the design to be stronger than debug info and accept the
performance impact that implies while trying to minimize it as
much as possible. We might have to extend the notion of operand
bundles to other instruction types, but the fundamental mechanism
is already in the IR. <br>
<br>
Philip<br>
<br>
On 12/07/2016 09:01 AM, Robinson, Paul via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:E3B07FDB86BFF041819DC057DEED8FEAF49589D9@USCULXMSG08.am.sony.com"
type="cite">
<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;}
span.EmailStyle17
{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]-->
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in">I don't see how
ASan and debuggers are different. It feels like both need
reasonably accurate source location attribution for any
instruction. ASan just happens to care more about loads and
stores than interactive stepping debuggers.<o:p></o:p></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">Actually
they are pretty different in their requirements.<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">ASan
cares about *accurate* source location info for *specific*
instructions, the ones that do something ASan cares about.
The source attributions for any other instruction is
irrelevant to ASan. The source attributions for these
instructions *must* survive optimization.<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">Debuggers
care about *useful* source location info for *sets* of
instructions, i.e. the instructions related to some
particular source statement. If that set is only 90%
complete/accurate, instead of 100%, generally that doesn't
adversely affect the user experience. If you step past
statement A, and happen to execute one or two instructions
from the next statement B before you actually stop,
generally that is not important to the user. Debuggers are
able to tolerate a moderate amount of slop in the source
attributions, because absolute accuracy is not critical to
correct operation of the debugger. This is why
optimizations can get away with dropping attributions that
are difficult to represent accurately.<o:p></o:p></span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">ASan
should be able to encode source info for just the
instructions it cares about, e.g. pass an index or other
encoded representation to the RT calls. Being actual
parameters, they will survive any correct optimization,
unlike today's situation where multiple calls might be
merged by an optimization, damaging the correctness of ASan
reports. (We've see this exact thing happen.) ASan does
not need a line table mapping all instructions back to their
source; it needs a parameter at each call (more or less).
It does need a file table, that's the main bit of redundancy
with debug info that I see happening.<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"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></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"">
Reid Kleckner [<a class="moz-txt-link-freetext" href="mailto:rnk@google.com">mailto:rnk@google.com</a>]
<br>
<b>Sent:</b> Wednesday, December 07, 2016 8:23 AM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> Hal Finkel; David Blaikie;
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm-dev] Debug Locations for
Optimized Code<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Wed, Dec 7, 2016 at 7:39 AM,
Robinson, Paul via llvm-dev <<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<o:p></o:p></p>
<p class="MsoNormal">When we are looking at a situation
where an instruction is merely *moved*<br>
from one place to another, retaining the source
location and having a<br>
less naïve statement-marking tactic could help the
debugging experience<br>
without perturbing other consumers (although one still
wonders whether<br>
profiles will get messed up in cases where e.g. a loop
invariant gets<br>
hoisted out of a cold loop into a hot predecessor).<br>
<br>
When we are looking at a situation where two
instructions are *merged* or<br>
*combined* into one, and the original two instructions
had different<br>
source locations, that's a separate problem. In that
case there is no<br>
single correct source location for the new
instruction, and typically<br>
erasing the source location will give a better
debugging experience (also<br>
a less misleading profile).<br>
<br>
My personal opinion is that having sanitizers *rely*
on debug info for<br>
accurate source attribution is just asking for
trouble. It happens to<br>
work at –O0 but cannot be considered reliable in the
face of optimization.<br>
IMO this is a fundamental design flaw; debug info is
best-effort and full<br>
of ambiguities, as shown above. Sanitizers need a more
reliable<br>
source-of-truth, i.e. they should encode source info
into their own<br>
instrumentation.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I don't see how ASan and
debuggers are different. It feels like both need
reasonably accurate source location attribution for
any instruction. ASan just happens to care more
about loads and stores than interactive stepping
debuggers.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It really doesn't make sense for
ASan to invent another mechanism to track source
location information. Any mechanism we build would
be so redundant with debug info that, as an
implementation detail, we would find a way to make
them use the same storage when possible. With that
in mind, maybe we should really find a way to mark
source locations as "hoisted" or "sunk" so that we
can suppress them from our line tables or do
something else clever.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>