Mention predicting exception catch at throw site

llvm-svn: 354914
This commit is contained in:
Jim Ingham 2019-02-26 19:18:09 +00:00
parent d44db7e486
commit cbf575a5a0
2 changed files with 47 additions and 0 deletions

View File

@ -394,3 +394,24 @@ remote memory and its function calling support is very rudimentary. It would be
useful to unify these and make the IR interpreter -- both for LLVM and LLDB --
better. An alternate strategy would be simply to JIT into the current process
but have callbacks for non-stack memory access.
Teach lldb to predict exception propagation at the throw site
-------------------------------------------------------------
There are a bunch of places in lldb where we need to know at the point where an
exception is thrown, what frame will catch the exception.
For instance, if an expression throws an exception, we need to know whether the
exception will be caught in the course of the expression evaluation. If so it
would be safe to let the expression continue. But since we would destroy the
state of the thread if we let the exception escape the expression, we currently
stop the expression evaluation if we see a throw. If we knew where it would be
caught we could distinguish these two cases.
Similarly, when you step over a call that throws, you want to stop at the throw
point if you know the exception will unwind past the frame you were stepping in,
but it would annoying to have the step abort every time an exception was thrown.
If we could predict the catching frame, we could do this right.
And of course, this would be a useful piece of information to display when stopped
at a throw point.

View File

@ -467,6 +467,32 @@
access.
</p>
</li>
<li>
Teach lldb to predict exception propagation at the throw site
<p>
There are a bunch of places in lldb where we need to know at the point where an
exception is thrown, what frame will catch the exception.
</p>
<p>
For instance, if an expression throws an exception, we need to know whether the
exception will be caught in the course of the expression evaluation. If so it
would be safe to let the expression continue. But since we would destroy the
state of the thread if we let the exception escape the expression, we currently
stop the expression evaluation if we see a throw. If we knew where it would be
caught we could distinguish these two cases.
</p>
<p>
Similarly, when you step over a call that throws, you want to stop at the throw
point if you know the exception will unwind past the frame you were stepping in,
but it would annoying to have the step abort every time an exception was thrown.
If we could predict the catching frame, we could do this right.
</p>
<p>
And of course, this would be a useful piece of information to display when stopped
at a throw point.
</p>
</li>
</ol>
</div>
<div class="postfooter"></div>