<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;}
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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<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?<o:p></o:p></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>
<o:p></o:p></p>
<p class="MsoNormal"><a name="_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.<o:p></o:p></span></a></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""> David Blaikie [mailto:dblaikie@gmail.com]
<br>
<b>Sent:</b> Wednesday, December 07, 2016 10:27 AM<br>
<b>To:</b> Hal Finkel; Robinson, Paul<br>
<b>Cc:</b> llvm-dev@lists.llvm.org<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>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Dec 7, 2016 at 10:20 AM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<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-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?<o:p></o:p></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<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <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-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<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>