<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 7, 2016 at 10:20 AM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br class="gmail_msg">
> From: "Paul Robinson" <<a href="mailto:paul.robinson@sony.com" class="gmail_msg" target="_blank">paul.robinson@sony.com</a>><br class="gmail_msg">
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" class="gmail_msg" target="_blank">hfinkel@anl.gov</a>>, "David Blaikie" <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>><br class="gmail_msg">
> Cc: <a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="gmail_msg">
> Sent: Wednesday, December 7, 2016 9:39:16 AM<br class="gmail_msg">
> Subject: RE: [llvm-dev] Debug Locations for Optimized Code<br class="gmail_msg">
><br class="gmail_msg">
> >> I don't know what the right, if any, solution to this is - but I<br class="gmail_msg">
> >> thought I should bring it up in case you or anyone else wanted to<br class="gmail_msg">
> >> puzzle it over & see if the competing needs/desires might need to<br class="gmail_msg">
> >> be<br class="gmail_msg">
> >> considered.<br class="gmail_msg">
> > One thing that I recall being discussed was changing the way that<br class="gmail_msg">
> > we<br class="gmail_msg">
> > set the is_stmt flag in the DWARF line-table information. As I<br class="gmail_msg">
> > understand it, we currently set this flag for the first instruction<br class="gmail_msg">
> > in<br class="gmail_msg">
> > any sequence that is on the same line. This is, in part, why the<br class="gmail_msg">
> > debugger appears to jump around when stepping through code with<br class="gmail_msg">
> > speculated instructions, etc. If we did not do this for<br class="gmail_msg">
> > out-of-place<br class="gmail_msg">
> > instructions, then we might be able to keep for debugging<br class="gmail_msg">
> > information<br class="gmail_msg">
> > for tools while still providing a reasonable debugging experience.<br class="gmail_msg">
><br class="gmail_msg">
> When we are looking at a situation where an instruction is merely<br class="gmail_msg">
> *moved*<br class="gmail_msg">
> from one place to another, retaining the source location and having a<br class="gmail_msg">
> less naïve statement-marking tactic could help the debugging<br class="gmail_msg">
> experience<br class="gmail_msg">
> without perturbing other consumers (although one still wonders<br class="gmail_msg">
> whether<br class="gmail_msg">
> profiles will get messed up in cases where e.g. a loop invariant gets<br class="gmail_msg">
> hoisted out of a cold loop into a hot predecessor).<br class="gmail_msg">
><br class="gmail_msg">
> When we are looking at a situation where two instructions are<br class="gmail_msg">
> *merged* or<br class="gmail_msg">
> *combined* into one, and the original two instructions had different<br class="gmail_msg">
> source locations, that's a separate problem.  In that case there is<br class="gmail_msg">
> no<br class="gmail_msg">
> single correct source location for the new instruction, and typically<br class="gmail_msg">
> erasing the source location will give a better debugging experience<br class="gmail_msg">
> (also<br class="gmail_msg">
> a less misleading profile).<br class="gmail_msg">
<br class="gmail_msg">
Is there a reason why we must only have one location for every instruction? If not, why not merge them and keep them all?<br class="gmail_msg"></blockquote><div><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</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
 -Hal<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> My personal opinion is that having sanitizers *rely* on debug info<br class="gmail_msg">
> for<br class="gmail_msg">
> accurate source attribution is just asking for trouble.  It happens<br class="gmail_msg">
> to<br class="gmail_msg">
> work at –O0 but cannot be considered reliable in the face of<br class="gmail_msg">
> optimization.<br class="gmail_msg">
> IMO this is a fundamental design flaw; debug info is best-effort and<br class="gmail_msg">
> full<br class="gmail_msg">
> of ambiguities, as shown above. Sanitizers need a more reliable<br class="gmail_msg">
> source-of-truth, i.e. they should encode source info into their own<br class="gmail_msg">
> instrumentation.<br class="gmail_msg">
><br class="gmail_msg">
> --paulr<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Hal Finkel<br class="gmail_msg">
Lead, Compiler Technology and Programming Languages<br class="gmail_msg">
Leadership Computing Facility<br class="gmail_msg">
Argonne National Laboratory<br class="gmail_msg">
</blockquote></div></div>