[Docs] Remove reproducers from the project page.

Jim pointed out that this was still open on the website.

llvm-svn: 367066
This commit is contained in:
Jonas Devlieghere 2019-07-25 22:22:43 +00:00
parent 7296fac558
commit 29af3b4e67
1 changed files with 7 additions and 22 deletions

View File

@ -291,21 +291,6 @@ state at StopPoint 0, StopPoint 1, etc. These could then be used for testing
reactions to complex threading problems & the like, and also for simulating reactions to complex threading problems & the like, and also for simulating
hard-to-test environments (like bare board debugging). hard-to-test environments (like bare board debugging).
A Bug-Trapper infrastructure
----------------------------
We very often have bugs that can't be reproduced locally. So having a
bug-report-trapper that can gather enough information from the surroundings of
a bug so that we can replay the session locally would be a big help tracking
down issues in this situation. This is tricky because you can't necessarily
require folks to leak information about their code in order to file bug
reports. So not only will you have to figure out what state to gather, you're
also going to have to anonymize it somehow. But we very often have bugs from
people that can't reduce the problem to a simple test case and can't give us
our code, and we often just can't help them as things stand now. Note that
adding the ProcessMock would be a good first stage towards this, since you
could make a ProcessMock creator/serializer from the current lldb state.
Expression parser needs syntax for "{symbol,type} A in CU B.cpp" Expression parser needs syntax for "{symbol,type} A in CU B.cpp"
---------------------------------------------------------------- ----------------------------------------------------------------
@ -393,21 +378,21 @@ 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 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. exception is thrown, what frame will catch the exception.
For instance, if an expression throws an exception, we need to know whether the 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 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 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 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 stop the expression evaluation if we see a throw. If we knew where it would be
caught we could distinguish these two cases. caught we could distinguish these two cases.
Similarly, when you step over a call that throws, you want to stop at the throw 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, 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. 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. 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 And of course, this would be a useful piece of information to display when stopped
at a throw point. at a throw point.
Add predicates to the nodes of settings Add predicates to the nodes of settings