diff options
| -rwxr-xr-x | lldb/www/projects.html | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/lldb/www/projects.html b/lldb/www/projects.html index 989f090a2e4..7c3bebdd052 100755 --- a/lldb/www/projects.html +++ b/lldb/www/projects.html @@ -200,6 +200,24 @@ </li> <li> + Recover thread information lazily + <p> + LLDB stores all the user intentions for a thread in the ThreadPlans stored in + the Thread class. That allows us to reliably implement a very natural model for + users moving through a debug session. For example, if step-over stops at a breakpoint + in an function in a younger region of the stack, continue will complete the step-over + rather than having to manually step out. But that means that it is important that + the Thread objects live as long as the Threads they represent. For programs with many + threads, but only one that you are debugging, that makes stepping less efficient, + since now you have to fetch the thread list on every step or stepping doesn't work + correctly. This is especially an issue when the threads are provided by an + Operating System plugin, where it may take non-trivial work to reconstruct the + thread list. It would be better to fetch threads lazily but keep "unseen" threads in + a holding area, and only retire them when we know we've fetched the whole thread list + and ensured they are no longer alive. + </p> + </li> + <li> Add an extension point in the breakpoint search machinery. <p> This would allow highly customizable, algorithmic breakpoint types, like "break on every |
