[all-commits] [llvm/llvm-project] 671e28: [lldb] Enable chaining multiple scripted frame pro...
Adrian Vogelsgesang via All-commits
all-commits at lists.llvm.org
Mon Feb 9 01:52:51 PST 2026
Branch: refs/heads/release/22.x
Home: https://github.com/llvm/llvm-project
Commit: 671e287b9c4c78e6d58494bc3ec80b941092c60c
https://github.com/llvm/llvm-project/commit/671e287b9c4c78e6d58494bc3ec80b941092c60c
Author: Med Ismail Bennani <ismail at bennani.ma>
Date: 2026-02-09 (Mon, 09 Feb 2026)
Changed paths:
M lldb/include/lldb/Target/StackFrameList.h
M lldb/include/lldb/Target/Thread.h
M lldb/source/Target/StackFrameList.cpp
M lldb/source/Target/Thread.cpp
M lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py
M lldb/test/API/functionalities/scripted_frame_provider/test_frame_providers.py
Log Message:
-----------
[lldb] Enable chaining multiple scripted frame providers per thread (#172849)
This patch allows threads to have multiple SyntheticFrameProviderSP
instances that chain together sequentially. Each provider receives the
output of the previous provider as input, creating a transformation
pipeline.
It changes `Thread::m_frame_provider_sp` to a vector, adds provider
parameter to SyntheticStackFrameList to avoid calling back into
`Thread::GetFrameProvider()` during frame fetching, updated
`LoadScriptedFrameProvider()` to chain providers by wrapping each
previous provider's output in a `SyntheticStackFrameList` for the next
provider and finally, loads ALL matching providers in priority order
instead of just the first one.
The chaining works as follows:
```
Real Unwinder Frames
↓
Provider 1 (priority 10) → adds/transforms frames
↓
Provider 2 (priority 20) → transforms Provider 1's output
↓
Provider 3 (priority 30) → transforms Provider 2's output
↓
Final frame list shown to user
```
This patch also adds a test for this (test_chained_frame_providers) to verify that 3 providers chain correctly: `AddFooFrameProvider`, `AddBarFrameProvider`, `AddBazFrameProvider`.
Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>
(cherry picked from commit 17b01bbc67c484068e174d9e9a80089102bea0e8)
Commit: 5d50168a207adc174831f91623b953fdc7b89779
https://github.com/llvm/llvm-project/commit/5d50168a207adc174831f91623b953fdc7b89779
Author: Leandro Lupori <leandro.lupori at linaro.org>
Date: 2026-02-09 (Mon, 09 Feb 2026)
Changed paths:
M lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py
M lldb/test/API/functionalities/scripted_frame_provider/test_frame_providers.py
Log Message:
-----------
[lldb] Fix test_chained_frame_providers on 32-bit Arm (#177668)
PC addresses must always be 16-bit aligned on 32-bit Arm CPUs.
Fixes #177666
(cherry picked from commit cd70e2d8367493785f1591045db2151540b14b91)
Commit: 341793b5924094328480d64878ebedf9f1745b16
https://github.com/llvm/llvm-project/commit/341793b5924094328480d64878ebedf9f1745b16
Author: Aman LaChapelle <aman.lachapelle at gmail.com>
Date: 2026-02-09 (Mon, 09 Feb 2026)
Changed paths:
M lldb/include/lldb/API/SBValue.h
M lldb/include/lldb/ValueObject/ValueObject.h
M lldb/source/API/SBValue.cpp
M lldb/source/ValueObject/ValueObject.cpp
Log Message:
-----------
[lldb] Move ValueImpl and ValueLocker to ValueObject, NFC. (#178573)
This patch moves ValueImpl and ValueLocker to ValueObject.{h,cpp}. This follows the example set in TypeImpl/SBType, where we have something that SBType uses internally that needs to be exposed in the layer below. In this case, SBValue uses ValueImpl, which wraps ValueObject. The wrapper helps avoid bugs, so we want to keep it, but the script interpreter needs to use it and said interpreter is conceptually *below* the SB layer...which means we can't use methods on SBValue.
This patch is purely the code motion part of that, future patches will actually make use of this moved code.
(cherry picked from commit 58f623c504d14743e465f988848f9c16dc220a3b)
Commit: 4baddb742729f124010360bcfde293a332267a7a
https://github.com/llvm/llvm-project/commit/4baddb742729f124010360bcfde293a332267a7a
Author: Aman LaChapelle <aman.lachapelle at gmail.com>
Date: 2026-02-09 (Mon, 09 Feb 2026)
Changed paths:
M lldb/bindings/python/python-wrapper.swig
M lldb/include/lldb/API/SBValue.h
M lldb/include/lldb/Interpreter/ScriptInterpreter.h
M lldb/source/Interpreter/ScriptInterpreter.cpp
M lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.cpp
M lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPythonInterface.h
M lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
Log Message:
-----------
[lldb] Add conversions for SBValueList and SBValue to the python bridge. (#178574)
This patch adds support for:
- PyObject -> SBValueList (which was surprisingly not there before!)
- PyObject -> SBValue
- SBValue -> ValueObjectSP using the ScriptInterpreter
These three are the main remaining plumbing changes necessary before we can get to the meat of actually using ScriptedFrame to provide values to the printer/etc. Future patches build off this change in order to allow ScriptedFrames to provide variables and get values for variable expressions.
(cherry picked from commit 8122d0e4bc8b536e0bb6bb5fae97e8216986ee28)
Commit: 6b5252ee78670efdf0966084b1d3b5f1829e18ba
https://github.com/llvm/llvm-project/commit/6b5252ee78670efdf0966084b1d3b5f1829e18ba
Author: Aman LaChapelle <aman.lachapelle at gmail.com>
Date: 2026-02-09 (Mon, 09 Feb 2026)
Changed paths:
M lldb/include/lldb/Interpreter/Interfaces/ScriptedFrameInterface.h
M lldb/source/Plugins/Process/scripted/ScriptedFrame.cpp
M lldb/source/Plugins/Process/scripted/ScriptedFrame.h
M lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedFramePythonInterface.cpp
M lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedFramePythonInterface.h
M lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py
M lldb/test/API/functionalities/scripted_frame_provider/main.cpp
M lldb/test/API/functionalities/scripted_frame_provider/test_frame_providers.py
Log Message:
-----------
[lldb] Add support for ScriptedFrame to provide values/variables. (#178575)
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
Related radar: rdar://165708771
(cherry picked from commit 10f2611c2173783efae8aebc32d1515013271b64)
Commit: 6fc6d00fe61c1ac7f70d995d39bd6e8b94624f5d
https://github.com/llvm/llvm-project/commit/6fc6d00fe61c1ac7f70d995d39bd6e8b94624f5d
Author: Med Ismail Bennani <ismail at bennani.ma>
Date: 2026-02-09 (Mon, 09 Feb 2026)
Changed paths:
M lldb/include/lldb/Target/ExecutionContext.h
M lldb/include/lldb/Target/StackFrame.h
M lldb/include/lldb/Target/StackFrameList.h
M lldb/include/lldb/Target/Thread.h
M lldb/include/lldb/lldb-defines.h
M lldb/include/lldb/lldb-types.h
M lldb/source/Target/ExecutionContext.cpp
M lldb/source/Target/StackFrameList.cpp
M lldb/source/Target/Thread.cpp
M lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py
M lldb/test/API/functionalities/scripted_frame_provider/main.cpp
A lldb/test/API/macosx/extended-backtrace-api/Makefile
A lldb/test/API/macosx/extended-backtrace-api/TestExtendedBacktraceAPI.py
A lldb/test/API/macosx/extended-backtrace-api/main.m
Log Message:
-----------
[lldb] Fix variable access in old SBFrames after inferior function calls (#178823)
When a user holds an SBFrame reference and then triggers an inferior
function
call (via expression evaluation or GetExtendedBacktraceThread),
variables in
that frame become inaccessible with "register fp is not available"
errors.
This happens because inferior function calls execute through
ThreadPlanCallFunction, which calls ClearStackFrames() during cleanup to
invalidate the unwinder state. ExecutionContextRef objects in the old
SBFrames
were tracking StackFrameLists via weak_ptr, which became stale when
ClearStackFrames() created new instances.
The fix uses stable StackFrameList identifiers that persist across
ClearStackFrames():
- ID = 0: Normal unwinder frames (constant across all instances)
- ID = sequential counter: Scripted frame provider instances
ExecutionContextRef now stores the frame list ID instead of a weak_ptr,
allowing
it to resolve to the current StackFrameList with fresh unwinder state
after an
inferior function call completes.
The Thread object preserves the provider chain configuration
(m_provider_chain_ids and m_next_provider_id) across ClearStackFrames()
so
that recreated StackFrameLists get the same IDs. When providers need to
be
recreated, GetStackFrameList() rebuilds them from the persisted
configuration.
This commit also fixes a deadlock when Python scripted frame providers
call
back into LLDB during frame fetching. The m_list_mutex is now released
before
calling GetFrameAtIndex() on the Python scripted frame provider to
prevent
same-thread deadlock. A dedicated m_unwinder_frames_sp member ensures
GetFrameListByIdentifier(0) always returns the current unwinder frames,
and
proper cleanup in DestroyThread() and ClearStackFrames() to prevent
modules
from lingering after a Thread (and its StackFrameLists) gets destroyed.
Added test validates that variables remain accessible after
GetExtendedBacktraceThread triggers an inferior function call to fetch
libdispatch Queue Info.
rdar://167027676
Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>
(cherry picked from commit c373d7632ac1fe8374b7f2b9536d7e746ed24786)
Commit: bc604c7ed648834b430c144c02f5cb87a0b4711f
https://github.com/llvm/llvm-project/commit/bc604c7ed648834b430c144c02f5cb87a0b4711f
Author: Adrian Vogelsgesang <avogelsgesang at salesforce.com>
Date: 2026-02-09 (Mon, 09 Feb 2026)
Changed paths:
M lldb/include/lldb/Target/Target.h
M lldb/source/Target/Target.cpp
M lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py
Log Message:
-----------
[lldb] Broadcast `eBroadcastBitStackChanged` when frame providers change (#171482)
We want to reload the call stack whenever the frame providers are
updated. To do so, we now emit a `eBroadcastBitStackChanged` on all
threads whenever any changes to the frame providers take place.
I found this very useful while iterating on a frame provider in
lldb-dap. So far, the new frame provider only took effect after
continuing execution. Now the backtrace in VS-Code gets refreshed
immediately upon running `target frame-provider add`.
(cherry picked from commit 943782be5aec5db854065145dd73a618c3a775be)
Compare: https://github.com/llvm/llvm-project/compare/401d7166ed10...bc604c7ed648
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list