Re-land https://github.com/llvm/llvm-project/pull/180101 since it was
reverted here https://github.com/llvm/llvm-project/pull/182431 because
of a flaky test. This PR include the modified test that should pass from
https://github.com/llvm/llvm-project/pull/182415 :
When multiple threads are stopped at the same breakpoint, LLDB currently
steps each thread over the breakpoint one at a time. Each step requires
disabling the breakpoint, single-stepping one thread, and re-enabling
it, resulting in N disable/enable cycles and N individual vCont packets
for N threads. This is a common scenario for hot breakpoints in
multithreaded programs and scales poorly.
This patch batches the step-over so that all threads at the same
breakpoint site are stepped together in a single vCont packet, with the
breakpoint disabled once at the start and re-enabled once after the last
thread finishes.
At the top of WillResume, any leftover StepOverBreakpoint plans from a
previous cycle are popped with their re-enable side effect suppressed
via SetReenabledBreakpointSite, giving a clean slate.
SetupToStepOverBreakpointIfNeeded then creates fresh plans for all
threads that still need to step over a breakpoint, and these are grouped
by breakpoint address.
For groups with multiple threads, each plan is set to defer its
re-enable through SetDeferReenableBreakpointSite. Instead of re-enabling
the breakpoint directly when a plan completes, it calls
ThreadFinishedSteppingOverBreakpoint, which decrements a per-address
tracking count. The breakpoint is only re-enabled when the count reaches
zero.
All threads in the largest group are resumed together in a single
batched vCont packet. If some threads don't complete their step in one
cycle, the pop-and-recreate logic naturally re-batches the remaining
threads on the next WillResume call.
For 10 threads at the same breakpoint, this reduces the operation from
10 z0/Z0 pairs and 10 vCont packets to 1 z0 + 1 Z0 and a few
progressively smaller batched vCont packets.
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
There are two different ways to debug FreeBSD's kernel: core and remote
debugging. Remote debugging is done through `gdb-remote` plugin while
kernel dump and live core debugging is done through `freebsd-kernel`.
The name `freebsd-kernel` is vague for this reason, and following
`elf-core` and `mach-core`'s example, it would be clearer if this plugin
is renamed to `freebsd-kernel-core`.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
After https://github.com/llvm/llvm-project/pull/182297, we started generated `-gsimple-template-names` debug-info by default on macOS. The test was expecting template parameters in the error message. But with `simple-template-names` typenames would not contain template parameters (unless LLDB reconstructs them to do so). This formatter test was expecting template parameters, which would fail on macOS > 26.
Because the test is just concerned with checking that the `std::valarray` formatter works as expected (not that LLDB can retrieve typenames with/without template names), this patch relaxes the assertion.
In a follow-up we should fix up any type-name printing that would break with `simple-template-names`.
PR to fix failing test from
https://github.com/llvm/llvm-project/pull/180101 .
Fix the integration test to be resilient to non-deterministic thread
timing. Instead of requiring exact z0/Z0 counts, verify that batching
reduced toggles compared to one at a time stepping.
Also added: skip on `aarch64` where thread scheduling makes batching
unreliable.
Ran the test 20 times, passed all 20.
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
Following up from
https://discourse.llvm.org/t/improving-performance-of-multiple-threads-stepping-over-the-same-breakpoint/89637
When multiple threads are stopped at the same breakpoint, LLDB currently
steps each thread over the breakpoint one at a time. Each step requires
disabling the breakpoint, single-stepping one thread, and re-enabling
it, resulting in N disable/enable cycles and N individual vCont packets
for N threads.
Now we batch the step-over so that all threads at the same breakpoint
site are stepped together in a single vCont packet, with the breakpoint
disabled once at the start and re-enabled once after the last thread
finishes.
When we hit `WillResume` any leftover `StepOverBreakpoint` plans from a
previous cycle are popped with their re-enable side effect suppressed
via `SetReenabledBreakpointSite`, giving a clean slate.
`SetupToStepOverBreakpointIfNeeded` then creates fresh plans for all
threads that still need to step over a breakpoint, and these are grouped
by breakpoint address.
For groups with multiple threads, each plan is set to defer its
re-enable through `SetDeferReenableBreakpointSite`. Instead of
re-enabling the breakpoint directly when a plan completes, it calls
`ThreadFinishedSteppingOverBreakpoint`, which decrements a tracking
count per address. The breakpoint is only re-enabled when the count
reaches zero.
All threads in the largest group are resumed together in a single
batched vCont packet. If some threads don't complete their step in one
cycle, the pop-and-recreate logic naturally re-batches the remaining
threads on the next WillResume call.
Claude AI assisted in syntex fixes and making the comments more
understandable.
---------
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
#181283 removed fvc but it still remains in tests. This causes testing
on non-FreeBSD hosts. Thus add `skipUnlessPlatform` decorator.
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
PR #181720 introduced shared builds for LLDB API tests to improve test
efficiency. But several data formatter tests requiring PDB debug info
are failing on Windows x64 and AArch64 platforms.
This patch disables shared builds for these tests by setting
SHARED_BUILD_TESTCASE = False
The shared build optimization breaks these tests because they reuse
build artifacts between test methods
The test runs may could use multiple methods with different debug
formats or compiler flags. When a test runs first it builds with one set
of flags, but then it runs again but **make** sees the source unchanged
so it skips rebuilding and reuses the same old binary instead of
rebuilding with correct flags.
This changes Python API tests to use a single build shared across all
test functions, instead of the previous default behavior of a separate
build dir for each test function.
This build behavior opt-out, tests can use the previous behavior of one
individual (unshared) build directory per test function, by setting
`SHARED_BUILD_TESTCASE` to False (in the test class).
The motivation is to make the test suite more efficient, by not
repeatedly building the same test source. When running tests on my macOS
machine, this reduces the time of `ninja check-lldb-api` by almost 60%
(sample numbers: from ~492s down to ~207s = 58%). Almost 5min time
saved.
Each test function still calls `self.build()`, but only the first call
will do a build, in the subsequent tests `make` will be a no-op because
the sources won't have changed.
This revert #181334 and its follow-up PRs (including #181488, #181492,
#181493, #181494 and #181498) as well as Ismail's documentation changes
(#181594, #181717). The original commit causes a test failure in CI
(https://github.com/llvm/llvm-project/issues/181938) but the more I look
at the patch, the more I'm convinced it was not ready to land. It will
be easier to iterate on the feedback by re-landing this than by using
post-commit review.
This patch fixes where ELF cores will report all threads as `STOP REASON
0`.
This was/is a large personal annoyance of mine; added a test to verify a
default elf core process/thread has no valid stop reason.
## Summary
- Move `GetScriptedSymbolLocatorClassName()` from inline in `Target.h`
to out-of-line in `Target.cpp` to avoid collision with Windows
`winuser.h` `#define GetClassName GetClassNameW` macro.
- Replace `LaunchSimple(None, None, os.getcwd())` with
`lldbutil.run_to_breakpoint_do_run()` in `test_locate_source_file` to
fix test failure on remote platforms where the local working directory
doesn't exist.
Fixes CI failures from #181334.
## Test plan
- [ ] Windows (aarch64-windows) build passes
- [ ] remote-linux-win test passes
- [ ] Existing ScriptedSymbolLocator tests pass on local platforms
Co-authored-by: Rahul Reddy Chamala <rachamal@meta.com>
## Summary
Based on discussion from
[RFC](https://discourse.llvm.org/t/rfc-python-callback-for-source-file-resolution/83545),
this PR adds a new `SymbolLocatorScripted` plugin that allows Python
scripts to implement custom symbol and source file resolution logic.
This enables downstream users to build custom symbol servers, source
file remapping, and build artifact resolution entirely in Python.
### Changes
- Adds `LocateSourceFile()` to the SymbolLocator plugin interface,
called during source path resolution with a fully loaded `ModuleSP`, so
the plugin has access to the module's UUID, file paths, and symbols.
- Adds `SymbolLocatorScripted` plugin that delegates all four
SymbolLocator methods (`LocateExecutableObjectFile`,
`LocateExecutableSymbolFile`, `DownloadObjectAndSymbolFile`,
`LocateSourceFile`) to a user-provided Python class.
- Adds `ScriptedSymbolLocatorPythonInterface` to bridge C++ calls to
Python, with proper GIL management and error handling.
- Results for `LocateSourceFile` are cached per (module UUID, source
file) pair.
- The Python class is configured via: `settings set
plugin.symbol-locator.scripted.script-class module.ClassName`
### Python class interface
```python
class MyLocator:
def __init__(self, exe_ctx, args): ...
def locate_source_file(self, module, original_source_file):
...
def locate_executable_object_file(self, module_spec): ...
def locate_executable_symbol_file(self, module_spec,
default_search_paths): ...
def download_object_and_symbol_file(self, module_spec,
force_lookup, copy_executable): ...
```
### Test plan
```
Added TestScriptedSymbolLocator.py with 3 test cases:
- test_locate_source_file — verifies the locator resolves source
files, receives a valid SBModule with UUID, and remaps paths correctly
- test_locate_source_file_none_fallthrough — verifies returning
None falls through to default LLDB resolution, and that having no script
class set works normally
- test_invalid_script_class — verifies graceful handling of
invalid class names without crashing
```
Co-authored-by: Rahul Reddy Chamala <rachamal@fb.com>
This patch adds __getitem__ method to the SBAPI list classes that were
missing subscript support, enabling Pythonic index access (e.g.,
list[0], list[-1]) in Python bindings.
The implementation adds __getitem__ to the following classes:
- SBStringList
- SBFileSpecList
- SBProcessInfoList
- SBMemoryRegionInfoList
- SBThreadCollection
- SBBreakpointList
- SBModuleSpecList
- SBTypeList
Each implementation follows the same pattern:
- Type validation (raises TypeError for non-integer indices)
- Range validation with negative index support (raises IndexError for
out-of-range)
- Delegates to the appropriate Get*AtIndex() method
The changes are in SWIG interface extension files (.i), implementing the
__getitem__ method in Python bindings while maintaining compatibility
with existing Get*AtIndex() API.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
StopCondition::SetText was computing the hash from the moved-from text
parameter instead of the stored m_text member. After std::move(text),
the source parameter becomes empty, causing the hash to always be
computed from an empty string.
This caused breakpoint condition updates to fail silently. When a user
modified a condition (e.g., from "x == y" to "x > y"), the hash remained
unchanged. Breakpoint locations use this hash to detect when conditions
need re-evaluation, so with a stale hash they would continue using
cached state for the old condition, triggering at incorrect locations.
The patch fixes this issue by computing the hash from m_text after the
move operation, ensuring it reflects the actual stored condition text.
It also adds API test that updates a breakpoint condition and verifies
the new condition is properly evaluated.
rdar://170191229
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Several languages support some sort of "breakpoint" function, which adds
ISA-specific instructions to generate an interrupt at runtime. However,
on some platforms, these instructions don't increment the program
counter. When LLDB sets these instructions it isn't a problem, as we
remove them before continuing, then re-add them after stepping over the
location. However, for breakpoint sequences that are part of the
inferior process, this doesn't happen - and so users might be left
unable to continue past the breakpoint without manually interfering with
the program counter.
This patch adds logic to LLDB to intercept SIGTRAPs, inspect the bytes
of the inferior at the program counter, and if the instruction looks
like a BRK or BKPT or similar, increment the pc by the size of the
instruction we found. This unifies platform behaviour (e.g. on x86_64,
LLDB debug sessions already look like this) and improves UX (in my
opinion, but I think it beats messing with stuff every break).
Some ISAs (like AArch64) require slightly different handling, as while
there are multiple possible instructions, we should be careful only to
find the ones likely to have been emitted by a compiler backend, and not
those inserted from (for example) the UB sanitizer, or any others.
There is an existing builtin-debugtrap test which was under the macos
folder before. I've now moved that to "functionalities", made it pure C
only, and updated it a little bit so that it works regardless of
platform.
What I've not done is change the existing code in debugserver which was
added by Jason Molenda about five years ago
(https://reviews.llvm.org/D91238, 92b036d). It might not be required any
more after this change. Reading the history there, it seems like it was
agreed that this behaviour (skipping over unknown bps) was the desired
end goal.
Fixes#56268
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This reverts commit cc7292056683f592c33055bb6456d509201654ec.
This patch causes two tests to unexpectedly pass:
1. lldb-api.functionalities/tsan/cpp_global_location/TestTsanCPPGlobalLocation.py
2. lldb-api.functionalities/tsan/global_location/TestTsanGlobalLocation.py
Reverting to fix premerge. Not fixing forward so someone who is familiar
with LLDB can take a look and make sure those tests now should pass.
Ran my python script from
https://github.com/llvm/llvm-project/pull/97043 over the repo again and
there were 2 duplicate test-cases that have been introduced since I last
did this.
Also one of the WASM classes had a duplicate method which I just
removed.
We have a problem when some code on the private state thread needs to
run an expression. The private state thread is the one that fetches
"raw" events from the Process Plugin and decides how to handle them. But
if the private state thread needs to fetch the processed events to drive
running an expression, it can't also be the thread processing the raw
events.
We solve this by swapping in a modal private state thread just to handle
the events from the expression evaluation. That worked until you could
cause the expression evaluation to happen from Python, because then it
wasn't just the fetching of events that matter, but also the state of
the process and the state of the runlocks. The modal private state
thread is really a modal version of the thread and its associated state.
This patch gathers all the relevant control parameters into a structure
which we can swap in and out when needed.
It also adds a test using the new "was_hit" breakpoint resolver
affordance, which, since it acts as an asynchronous breakpoint callback,
gets run on the private state thread, showing that with the change we
can call expressions in the `was_hit` callback without problems.
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`.
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@bennani.ma>
When setting the enabled state of a breakpoint name via the API, the
change was not being propagated to breakpoints using that name.
This was inconsistent with the CLI behaviour where `breakpoint name
configure --enable/--disable` correctly updates all associated
breakpoints.
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
## Description
Contribution to this topic [Rich Disassembler for
LLDB](https://discourse.llvm.org/t/rich-disassembler-for-lldb/76952),
this part.
```
The rich disassembler output should be exposed as structured data and made available through LLDB’s scripting API so more tooling could be built on top of this
```
----
This pr replaces #174847
As was suggested in [this
comment](https://github.com/llvm/llvm-project/pull/174847#issuecomment-3757015552),
implement access to variable annotations from `SBInstruction` class
itself.
Notes:
- ✅ did run black formatter on the python file;
## Testing
Run test with
```sh
./build/bin/lldb-dotest -v -p TestVariableAnnotationsDisassembler.py lldb/test/API/functionalities/disassembler-variables
```
all tests (9 existing + 1 newly added) are passing
<details>
<summary>screenshot 2026-01-23</summary>
build from the latest commit 08f00730b5768a8e3f7039d810084fabaaa24470
<img width="1506" height="562" alt="image"
src="https://github.com/user-attachments/assets/69516353-3432-47df-ae45-c40b51ec14c4"
/>
</details>
<details>
<summary>screenshot 2026-01-29</summary>
build from the latest commit f48a1a2c10f96a457ca6844be2ccc9406d3d57a0
<img width="1232" height="740" alt="image"
src="https://github.com/user-attachments/assets/9d104ce6-36c3-430b-98fe-f028f83a6b6d"
/>
</details>
---------
Signed-off-by: Nikita B <n2h9z4@gmail.com>
This patch adds the coreFilePath, if applicable, to the target
statistics for LLDB. My primary motivation here is sanity check user
reports when they say I had an issue with a specific corefile and then
validating it was in fact that specifies corefile, as right now there is
no guaruntee the filename and the process/target name will be the same.
the ubsan decorator previously assumes the platform is macOS.
macOS has an extra underscore in symbols names match two or more.
uses the llvm-nm that is built instead of the system's nm.
This patch enables ELF core files to be loaded and still show
executables and shared libraries. Functionality includes:
- Load executable and shared libraries from memory if ELF headers are
available
- Create placeholder for missing shared libraries and executable.
Previously you just wouldn't get anything in the "image list" if no
executable was provided.
"memory region" can be given an address once and then when repeated,
it will try to find a region just beyond the last one it printed.
This continues until the end of the address space.
Then it gives you an error showing the usage, which is odd because
you just saw a bunch of "memory region" with no options work.
So I've improved the error a bit to imply its to do with the repetition.
Then described the repeating behaviour in the help text.
When a server is unable to allocate memory for the `_M` packet, it may
respond with an error code. In this case,
`GDBRemoteCommunicationClient::AllocateMemory()` sets
`m_supports_alloc_dealloc_memory` to `eLazyBoolYes`; `eLazyBoolNo` is
only used if the server cannot handle the packet at all. Before this
patch, `ProcessGDBRemote::DoAllocateMemory()` checked this flag and
returned `LLDB_INVALID_ADDRESS` without setting an error, which caused
`Process::CanJIT()` to set `m_can_jit = eCanJITYes`, resulting in
`IRMemoryMap::FindSpace()` attempting to allocate memory in the inferior
process and failing. With the patch,
`ProcessGDBRemote::DoAllocateMemory()` returns an error and `m_can_jit`
is set to `eCanJITNo`.
Example debug session:
```
(lldb) platform connect...
(lldb) file test
(lldb) br set...
(lldb) run
Process 100 launched:...
Process 100 stopped
* thread #1,...
(lldb) expr $x0
error: Couldn't allocate space for materialized struct: Couldn't malloc: address space is full
error: errored out in virtual lldb_private::LLVMUserExpression::DoExecute, couldn't PrepareToExecuteJITExpression
```
When you specify a filename to `process save core`, we'll write it in
the current working directory. In Xcode the CWD is `/` and you can't
generally write there.
```
(lldb) process save-core --style full foo
error: failed to save core file for process: Read-only file system
```
This PR improves the error message by including the output file when we
can't save core. However, just printing the filename isn't that much
more helpful, because FileSystem::Resolve only makes a path absolute if
it exists.
```
error: failed to save core file for process to 'foo': Read-only file system
```
Therefore I also modified the interface to add a flag to force resolve a
potentially non-exist path.
```
error: failed to save core file for process to '/foo': Read-only file system
```
UBSAN stopped reporting the misaligned load since 5569bf26f0 so this test started failing. We skipped it to unblock CI.
There's been discussion on making UBSAN stricter and still trigger on
the one-line version of this. But for now, to get the test running
again, change it to a form which *does* trigger UBSAN.
Fixes https://github.com/llvm/llvm-project/issues/177064
