<div dir="ltr">my 2c. <div><br></div><div>the sanitizers rely on debug info to produce human-readable error messages,</div><div>and I agree with Reid that it's unwise to have a parallel way of encoding the source locations.</div><div><br></div><div>Well, we have something like this in the clang coverage already... Right?</div><div>(I never particularly liked this design decision).</div><div>But since the debug info is known to be unreliable it kind of made sense. Grrr. </div><div>And since the coverage instrumentation is applied early (in clang) we can do it. </div><div>asan/etc don't have this luxury. </div><div><br></div><div>The sanitizers do not actually rely hard on the correctness of debug info, <br></div><div>but lots of tests in compiler-rt expect the debug info to be sane. </div><div><br></div><div>If we break debug info in a way that affects the sanitizers two things may happen:</div><div>a) some of the existing *san tests in compiler-rt will start failing. That's usually easy to fix. </div><div>b) all tests will continue working but users will be getting less readable reports -- and we will learn about it 6 months from the time of breakage. </div><div>That's less welcome, but I am not sure if we can do something here. </div><div><br></div><div>--kcc </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 1:11 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_4100684268867685550WordSection1"><span class="">
<p class="MsoNormal" style="margin-left:1.0in">Is there a reason why we must only have one location for every instruction? If not, why not merge them and keep them all?<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in"><br>
Not a requirement - of course we could keep them all with some kind of ordered list and even potentially include a "this is the one we would've picked" info (eg: the first one's the one we would pick today, if we would've picked one rather than none) so we
could be backwards compatible if desired.<br>
<br>
That would be a lot of engineering work to plumb through LLVM the notion of multiple debug locations, I think.<br>
<br>
I'm not sure how DWARF (or CodeView) and its consumers currently copes with multiple locations - it's probably technically possible to describe using the line table format (not sure if it's intentional/documented for that purpose), but existing consumers might
have to be fixed not to trip over it.<br>
<br>
<u></u><u></u></p>
</span><p class="MsoNormal"><a name="m_4100684268867685550__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Technically the DWARF encoding of the line table does allow it, I've seen it happen, but not with the intent of describing two real
source locations; it was by accident. (And was one of the things that prompted me to submit patch D27492.) I seriously doubt any DWARF consumer takes the trouble to look for it. It's really not clear how a debugger *should* respond to seeing two source
locations for one instruction.<u></u><u></u></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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""> David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, December 07, 2016 10:27 AM<br>
<b>To:</b> Hal Finkel; 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] Debug Locations for Optimized Code<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, Dec 7, 2016 at 10:20 AM Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">----- Original Message -----<br>
> From: "Paul Robinson" <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>, "David Blaikie" <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
> Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Sent: Wednesday, December 7, 2016 9:39:16 AM<br>
> Subject: RE: [llvm-dev] Debug Locations for Optimized Code<br>
><br>
> >> I don't know what the right, if any, solution to this is - but I<br>
> >> thought I should bring it up in case you or anyone else wanted to<br>
> >> puzzle it over & see if the competing needs/desires might need to<br>
> >> be<br>
> >> considered.<br>
> > One thing that I recall being discussed was changing the way that<br>
> > we<br>
> > set the is_stmt flag in the DWARF line-table information. As I<br>
> > understand it, we currently set this flag for the first instruction<br>
> > in<br>
> > any sequence that is on the same line. This is, in part, why the<br>
> > debugger appears to jump around when stepping through code with<br>
> > speculated instructions, etc. If we did not do this for<br>
> > out-of-place<br>
> > instructions, then we might be able to keep for debugging<br>
> > information<br>
> > for tools while still providing a reasonable debugging experience.<br>
><br>
> When we are looking at a situation where an instruction is merely<br>
> *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<br>
> experience<br>
> without perturbing other consumers (although one still wonders<br>
> 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<br>
> *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<br>
> no<br>
> single correct source location for the new instruction, and typically<br>
> erasing the source location will give a better debugging experience<br>
> (also<br>
> a less misleading profile).<br>
<br>
Is there a reason why we must only have one location for every instruction? If not, why not merge them and keep them all?<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><br>
Not a requirement - of course we could keep them all with some kind of ordered list and even potentially include a "this is the one we would've picked" info (eg: the first one's the one we would pick today, if we would've picked one rather than none) so we
could be backwards compatible if desired.<br>
<br>
That would be a lot of engineering work to plumb through LLVM the notion of multiple debug locations, I think.<br>
<br>
I'm not sure how DWARF (or CodeView) and its consumers currently copes with multiple locations - it's probably technically possible to describe using the line table format (not sure if it's intentional/documented for that purpose), but existing consumers might
have to be fixed not to trip over it.<br>
<br>
It'd certainly be cute/fun/nice to have the extra fidelity (though all extra fidelity also comes at a size cost to the IR and the resulting object/executable files).<br>
<br>
Not sure anyone's in a position to sign up for that work right now - but maybe someone is. (looks like Apple's making a bit of a push on optimized debug info quality at the moment)<br>
<br>
- David<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
-Hal<br>
<br>
><br>
> My personal opinion is that having sanitizers *rely* on debug info<br>
> for<br>
> accurate source attribution is just asking for trouble. It happens<br>
> to<br>
> work at –O0 but cannot be considered reliable in the face of<br>
> optimization.<br>
> IMO this is a fundamental design flaw; debug info is best-effort and<br>
> 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.<br>
><br>
> --paulr<br>
><br>
><br>
<br>
--<br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<u></u><u></u></p>
</blockquote>
</div>
</div>
</div></div></div>
</div>
</div>
<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>
<br></blockquote></div><br></div>