[Lldb-commits] [lldb] [lldb/docs] Add scripting extensions documentation to the website (PR #97262)
via lldb-commits
lldb-commits at lists.llvm.org
Mon Jul 1 18:42:35 PDT 2024
================
@@ -0,0 +1,70 @@
+from abc import abstractmethod
+
+import lldb
+
+
+class ScriptedThreadPlan:
+ """
+ Class that provides data for an instance of a LLDB 'ScriptedThreadPlan' plug-in class used to construct custom stepping logic.
+
+ """
+
+ def __init__(self, thread_plan: lldb.SBThreadPlan):
+ """Initialization needs a valid lldb.SBThreadPlan object. This plug-in will get created after a live process is valid and has stopped.
+
+ Args:
+ thread_plan (lldb.SBThreadPlan): The underlying `ThreadPlan` that is pushed onto the plan stack.
+ """
+ self.thread_plan = thread_plan
+
+ def explains_stop(self, event: lldb.SBEvent) -> bool:
+ """Each plan is asked if it "explains" the stop. The first plan to claim the stop wins.
+
+ Args:
+ event (lldb.SBEvent): The process stop event.
+
+ Returns:
+ bool: `True` if this stop could be claimed by this thread plan, `False` otherwise.
+ Defaults to `True`.
+ """
+ return True
+
+ def is_stale(self) -> bool:
+ """If your plan is no longer relevant (for instance, you were stepping in a particular stack frame, but some other operation pushed that frame off the stack) return True and your plan will get popped.
+
+ Returns:
+ bool: `True` if this thread plan is stale, `False` otherwise.
+ Defaults to `True`.
+ """
+ return True
----------------
jimingham wrote:
Saying you are stale in case of error is appropriate for the Scripted Thread Plan runner plan. If the underlying Python code can't figure out what its state is, it's likely in a bad way and we should mark it as stale and get rid of it.
But these templates are more analogous to the base ThreadPlan than to the scripted plan runner.
That one does:
virtual bool IsPlanStale() { return false; }
https://github.com/llvm/llvm-project/pull/97262
More information about the lldb-commits
mailing list