]> granicus.if.org Git - clang/commit
DebugInfo: Use the preferred location rather than the start location for expression...
authorDavid Blaikie <dblaikie@gmail.com>
Sun, 25 Jan 2015 01:19:10 +0000 (01:19 +0000)
committerDavid Blaikie <dblaikie@gmail.com>
Sun, 25 Jan 2015 01:19:10 +0000 (01:19 +0000)
commit6d20e9041a49ab368d8d06e8366aa24788dfd1ac
tree7e2e9d06da86c0fa36f12d81922d7b4f07f319e8
parentc5d7b86ca03cca2ebd29694bbc27140930c21069
DebugInfo: Use the preferred location rather than the start location for expression line info

This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.

There were essentially 3 options for this:

* The beginning of an expression (this was the behavior prior to this
  commit). This meant that stepping through subexpressions would bounce
  around from subexpressions back to the start of the outer expression,
  etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
  where the actual addition occurred)).

* The end of an expression. This seems to be what GCC does /mostly/, and
  certainly this for function calls. This has the advantage that
  progress is always 'forwards' (never jumping backwards - except for
  independent subexpressions if they're evaluated in interesting orders,
  etc). "x + y + z" would go "x y z" with the additions occurring at y
  and z after the respective loads.
  The problem with this is that the user would still have to think
  fairly hard about precedence to realize which subexpression is being
  evaluated or which operator overload is being called in, say, an asan
  backtrace.

* The preferred location or 'exprloc'. In this case you get sort of what
  you'd expect, though it's a bit confusing in its own way due to going
  'backwards'. In this case the locations would be: "x y + z +" in
  lovely postfix arithmetic order. But this does mean that if the op+
  were an operator overload, say, and in a backtrace, the backtrace will
  point to the exact '+' that's being called, not to the end of one of
  its operands.

(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227027 91177308-0d34-0410-b5e6-96231b3b80d8
lib/CodeGen/CGDebugInfo.cpp
lib/CodeGen/CGDebugInfo.h
lib/CodeGen/CGExpr.cpp
lib/CodeGen/CGExprAgg.cpp
lib/CodeGen/CGExprCXX.cpp
lib/CodeGen/CGExprComplex.cpp
lib/CodeGen/CGExprScalar.cpp
test/CodeGenCXX/debug-info-line.cpp