[Lldb-commits] [lldb] [lldb] Introduce ScriptedFrameProvider for real threads (PR #161870)

[via lldb-commits]

jimingham wrote:

As far as registration goes, I think we should probably have a AppliesToThread type API as part of the ScriptedStackFrameList API.  Some of these providers might very well know "All the frames I am going to recognize are named with some recognizable pattern".  Or they might want to have a look at all frames.  

However, there should also be a way to override this from the command line or with the SBThread API so if I say something like:

`thread stack-provider add --python-class my-recognizer 5
`
then internally we override the Python `my_recognizer.applies_to_thread` with one that says "if thread index == 5".  If the ScriptedStackFrameList production is expensive and you only care about one thread, we shouldn't make you pay the cost for the others, regardless of what the provider thinks.

Since we don't want to force unwinding except when we really have to, the AppliesToThread should only check static data about the thread (like its name, etc.).  If your provider doesn't know whether it would apply without backtracing, it's probably better to just always ask it when backtracking the threads.  That's presuming that the task of "I don't have anything to add to the raw stack frame" is cheap, which it should be.

If you don't implement applies_to_thread, then it will default to getting inserted on all new thread.

https://github.com/llvm/llvm-project/pull/161870