[llvm-bugs] [Bug 43530] Single-stepping through clang-cl code randomly drops into assembly language

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43530

Reid Kleckner <rnk at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CONFIRMED                   |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Reid Kleckner <rnk at google.com> ---
I committed r374267 which avoids putting line zero in cv line tables.

(In reply to David Blaikie from comment #3)
> I don't think that's necessarily a problem/in tension. If CodeView has no
> way to represent ambiguous/unlocated instructions - then the line zero can
> be ignored & the previous instructions location can be propagated as is the
> behavior for some instructions that come from no particular location (I
> think the frontend creates some instructions with no location (not location
> zero, but no location at all) - so this is a supported flow/not a bug that's
> going to be fixed/etc)

Well, the more location-less instructions we have, the more important it
becomes to implement some kind of data flow analysis to backfill source
locations, when it might have been easier to keep them around during
optimization. This is what I wrote in the commit message of r374267:

    The fix is incomplete, because it's possible to have a basic block with
    no source locations at all. In this case, we don't emit a .cv_loc, but
    that will result in wrong stepping behavior in the debugger if the
    layout predecessor of the location-less BB has an unrelated source
    location. We could try harder to find a valid location that dominates or
    post-dominates the current BB, but in general it's a dataflow problem,
    and one still might not exist. I left a FIXME about this.

I think what I described there is a problem for DWARF as well. This is a sketch
of the what the situation would look like in assembly:

bbA:
  .loc 1
  jmp shared
bbB:
  .loc 2
  jmp shared
bbC:
  .loc 3
  ret
bbD:
  .loc 4
  ret
shared:
  # no loc
  cmp
  jcc bbC
  jmp bbD

In this case, the location-less block 'shared' would pick up the location from
it's layout predecessor, bbD, which depends on what block placement decides to
do. Layout tries to achieve as much fallthrough as possible, so I guess in
practice most line tables end up being smooth enough that we don't notice.
Anyway, there's a FIXME in the code for that case, but I think in practice
there are very few location-less BBs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191010/c6a086db/attachment.html>