[llvm-dev] Debug Locations for Optimized Code

[Reid Kleckner via llvm-dev]

On Wed, Dec 7, 2016 at 7:39 AM, Robinson, Paul via llvm-dev <
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/ce737e6c/attachment.html>