<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"David Blaikie via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>"llvm-dev" <llvm-dev@lists.llvm.org>, "Kostya Serebryany" <kcc@google.com><br><b>Sent: </b>Tuesday, December 6, 2016 10:38:50 PM<br><b>Subject: </b>[llvm-dev] Debug Locations for Optimized Code<br><br><div id="DWT9998" dir="ltr">Hi Kostya,<br><br>So... a bunch of folks (not all CC'd - feel free to add anyone who seems relevant, I haven't gone back over the commits to check who's made what changes) have been making improvements to optimized code debug information - much of it around making sure sample profiles are accurate.<br><br>This mostly entails removing debug locations from instructions that are moved between basic blocks.<br><br>The justification for this has usually been backed up by "it'll make users debug experience better too" because the debugger won't jump around so much, or give users misleading situations like "why am I stepped into a line of code in the 'if' block when the condition was clearly false" (because we raised a load that was done in both blocks up to before the branch and had to pick one of the two locations for it)<br><br>This may lead to reduction in quality of debug info for other uses - in particular in ASan and MSan at least.<br><br>ASan and MSan care a lot about loads and stores and the location where those came from - less so about whether the load or store was sunk into or out of a loop, etc. Dropping the locations entirely means the user has far less information about which load or store caused the invalid memory access. (The 'if' case is still tricky and would be confusing to a *San user as it was to a debug user.)<br></div></blockquote>I think that it is always potentially confusing: Having ASAN complain about a memory access from a loop that the code hasn't entered yet or has already completed is also difficult to decipher.<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><br>I don't know what the right, if any, solution to this is - but I thought I should bring it up in case you or anyone else wanted to puzzle it over & see if the competing needs/desires might need to be considered.<br></div></blockquote>One thing that I recall being discussed was changing the way that we set the is_stmt flag in the DWARF line-table information. As I understand it, we currently set this flag for the first instruction in any sequence that is on the same line. This is, in part, why the debugger appears to jump around when stepping through code with speculated instructions, etc. If we did not do this for out-of-place instructions, then we might be able to keep for debugging information for tools while still providing a reasonable debugging experience.<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><br>- Dave</div>
<br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>