[llvm-dev] Debug Locations for Optimized Code

[Robinson, Paul via llvm-dev]

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.

Actually they are pretty different in their requirements.

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.

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.

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.
--paulr

From: Reid Kleckner [mailto:rnk at google.com]
Sent: Wednesday, December 07, 2016 8:23 AM
To: Robinson, Paul
Cc: Hal Finkel; David Blaikie; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Debug Locations for Optimized Code

On Wed, Dec 7, 2016 at 7:39 AM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
When we are looking at a situation where an instruction is merely *moved*
from one place to another, retaining the source location and having a
less naïve statement-marking tactic could help the debugging experience
without perturbing other consumers (although one still wonders whether
profiles will get messed up in cases where e.g. a loop invariant gets
hoisted out of a cold loop into a hot predecessor).

When we are looking at a situation where two instructions are *merged* or
*combined* into one, and the original two instructions had different
source locations, that's a separate problem.  In that case there is no
single correct source location for the new instruction, and typically
erasing the source location will give a better debugging experience (also
a less misleading profile).

My personal opinion is that having sanitizers *rely* on debug info for
accurate source attribution is just asking for trouble.  It happens to
work at –O0 but cannot be considered reliable in the face of optimization.
IMO this is a fundamental design flaw; debug info is best-effort and full
of ambiguities, as shown above. Sanitizers need a more reliable
source-of-truth, i.e. they should encode source info into their own
instrumentation.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161207/103ae0c3/attachment.html>