The LLVM Coding Standards [1] specify that:
> [T]o match error message styles commonly produced by other tools,
> start the first sentence with a lowercase letter, and finish the last
> sentence without a period, if it would end in one otherwise.
Historically, that hasn't been something we've enforced in LLDB, but in
the past year or so I've started to pay more attention to this in code
reviews. This PR brings more error messages in compliance, further
increasing consistency.
I also adopted `createStringErrorV` where it improved the code as a
drive-by for lines I was already touching.
[1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages
Assisted-by: Claude Code
This makes the constructions of string errors more concise and more
consistent, mainly by removing the `inconvertibleErrorCode()`.
Additional changes replace `createStringError(formatv(...), ...)` with
`createStringErrorV(...)`.
Assisted-by: Claude
Make the interfaces part of lldbPluginScriptInterpreterPython instead of
putting them into their own static library. This avoids the need for an
extra static archive and more importantly a bunch of code duplication
between the two CMakeLists.txt.
The header guard is redundant because
`source/Plugins/ScriptInterpreter/CMakeLists.txt` already gates the
entire `Python/` subdirectory behind `LLDB_ENABLE_PYTHON`.
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.
## Summary
Use the standard `// LLDB Python header must be included first.` comment
to match every other Python interface `.cpp` file in this directory, as
suggested by @JDevlieghere.
## Test plan
NFC - comment only change.
Co-authored-by: Rahul Reddy Chamala <rachamal@meta.com>
## Summary
Move the definition of `ScriptInterpreter::MakeSBModuleSpec` from
`ScriptInterpreter.cpp` to `ScriptedPythonInterface.cpp`.
`MakeSBModuleSpec` constructs an `SBModuleSpec`, whose symbols live in
the API library (`liblldb`). `ScriptInterpreter.cpp` is part of
`lldbInterpreter`, which is also linked into `lldb-server` — and
`lldb-server` does not link the API library. On Windows, this causes
`LNK2019: unresolved external symbol` for `SBModuleSpec`'s constructor
and destructor.
`ScriptedPythonInterface.cpp` is part of the Python plugin library,
which only links into `liblldb` where the API symbols are available. The
method retains friend access to `SBModuleSpec` since it is still a
member of `ScriptInterpreter` regardless of which `.cpp` file defines
it.
Fixes Windows linker failure from #181334.
## Test plan
- [ ] Existing ScriptedSymbolLocator tests pass
Co-authored-by: Rahul Reddy Chamala <rachamal@meta.com>
## Summary
Include `lldb-python.h` as the first include inside the
`LLDB_ENABLE_PYTHON` block in `ScriptInterpreterPythonInterfaces.cpp`,
matching the pattern used by every other Python interface `.cpp` file in
this directory.
On Windows, `lldb-python.h` defines `NO_PID_T` before including
`Python.h`. This prevents `PosixApi.h` (transitively included via
`lldb-private.h`) from redefining `pid_t` with a conflicting type
(`uint32_t` vs `int`).
The issue was introduced by #181334 (ScriptedSymbolLocator plugin),
which added a new header whose include chain transitively reaches
`PosixApi.h`.
Fixes Windows build failures on lldb-aarch64-windows, lldb-x86_64-win,
and lldb-remote-linux-win.
## Test plan
- [ ] lldb-aarch64-windows build passes
- [ ] lldb-x86_64-win build passes
- [ ] lldb-remote-linux-win build passes
Co-authored-by: Rahul Reddy Chamala <rachamal@meta.com>
## Summary
- Move `#include "lldb/Core/PluginManager.h"` after `#include
"ScriptInterpreterPythonInterfaces.h"` so Python's `pyconfig.h` defines
`pid_t` before `PosixApi.h` gets included. This fixes the `C2371:
'pid_t': redefinition; different basic types` error on all Windows
builders.
Fixes CI failures from #181334 / #181488.
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>
Fix LLDB header guards using clang-tidy's llvm-header-guard check. A
bunch of headers have been moved or renamed and we often forget to
update the header guard.
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
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.
This patch adds `get_priority()` support to synthetic frame providers to
enable priority-based selection when multiple providers match a thread.
This is the first step toward supporting frame provider chaining for
visualizing coroutines, Swift async tasks, and et al.
Priority ordering follows Unix nice convention where lower numbers
indicate higher priority (0 = highest). Providers without explicit
priority return `std::nullopt`, which maps to UINT32_MAX (lowest
priority), ensuring backward compatibility with existing providers.
The implementation adds `GetPriority()` as a virtual method to
`SyntheticFrameProvider` base class, implements it through the scripting
interface hierarchy (`ScriptedFrameProviderInterface` and
`ScriptedFrameProviderPythonInterface`), and updates
`Thread::GetStackFrameList()` to sort applicable providers by priority
before attempting to load them.
Python frame providers can now specify priority:
```python
@staticmethod
def get_priority():
return 10 # Or return None for default priority.
```
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This adds a new virtual method `GetScriptedModulePath()` to
`ScriptedInterface` that allows retrieving the file path of the Python
module containing the scripted object implementation.
The Python implementation acquires the GIL and walks through the
object's `__class__.__module__` to find the module's `__file__`
attribute. This will be used by ScriptedFrame to populate the module and
compile unit for frames pointing to Python source files.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Extract `__func__` attribute from staticmethod/classmethod descriptors
before treating them as callables. Python's `@staticmethod` and
`@classmethod` decorators wrap methods in descriptor objects that are
not directly usable as PythonCallable, when calling PyCallable_Check.
The actual callable function is stored in the `__func__` attribute of
these descriptors, so we need to unwrap them to properly validate and
invoke the decorated methods in scripted interfaces.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This fixes a typo in ScriptedPythonInterface and changes
`AbstrackMethodCheckerPayload` to `AbstractMethodCheckerPayload`.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch extends ScriptedFrame to work with real (non-scripted)
threads,
enabling frame providers to synthesize frames for native processes.
Previously, ScriptedFrame only worked within
ScriptedProcess/ScriptedThread
contexts. This patch decouples ScriptedFrame from ScriptedThread,
allowing
users to augment or replace stack frames in real debugging sessions for
use
cases like custom calling conventions, reconstructing corrupted frames
from
core files, or adding diagnostic frames.
Key changes:
- ScriptedFrame::Create() now accepts ThreadSP instead of requiring
ScriptedThread, extracting architecture from the target triple rather
than ScriptedProcess.arch
- Added SBTarget::RegisterScriptedFrameProvider() and
ClearScriptedFrameProvider() APIs, with Target storing a
SyntheticFrameProviderDescriptor template for new threads
- Added "target frame-provider register/clear" commands for CLI access
- Thread class gains LoadScriptedFrameProvider(),
ClearScriptedFrameProvider(),
and GetFrameProvider() methods for per-thread frame provider management
- New SyntheticStackFrameList overrides FetchFramesUpTo() to lazily
provide
frames from either the frame provider or the real stack
This enables practical use of the SyntheticFrameProvider infrastructure
in
real debugging workflows.
rdar://161834688
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
parameters when defining the scripting interfaces.
We try to count the parameters to make sure the user has defined them
correctly, but this throws the counting off.
I'm not adding a test for this because then it would seem like we
thought this was a good idea. I'd actually rather not support it
altogether, but we added the parameter checking pretty recently so there
are extant implementations that we broke. I only want to support them,
not suggest anyone else do this going forward.
This patch implements the base and python interface for the
ScriptedFrameProvider class.
This is necessary to call python APIs from the ScriptedFrameProvider
that will come in a follow-up.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch adds the notion of "Facade" locations which can be reported
from a ScriptedResolver instead of the actual underlying breakpoint
location for the breakpoint. Also add a "was_hit" method to the scripted
resolver that allows the breakpoint to say which of these "Facade"
locations was hit, and "get_location_description" to provide a
description for the facade locations.
I apologize in advance for the size of the patch. Almost all of what's
here was necessary to (a) make the feature testable and (b) not break
any of the current behavior.
The motivation for this feature is given in the "Providing Facade
Locations" section that I added to the python-reference.rst so I won't
repeat it here.
rdar://152112327
This patch introduces a new scripting affordance in lldb:
`ScriptedFrame`.
This allows user to produce mock stackframes in scripted threads and
scripted processes from a python script.
With this change, StackFrame can be synthetized from different sources:
- Either from a dictionary containing a load address, and a frame index,
which is the legacy way.
- Or by creating a ScriptedFrame python object.
One particularity of synthezising stackframes from the ScriptedFrame
python object, is that these frame have an optional PC, meaning that
they don't have a report a valid PC and they can act as shells that just
contain static information, like the frame function name, the list of
variables or registers, etc. It can also provide a symbol context.
rdar://157260006
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
If we're not touching them, we don't need to do anything special to pass
them along -- with one important caveat: due to how cmake arguments
work, the implicitly passed arguments need to be specified before
arguments that we handle.
This isn't particularly nice, but the alternative is enumerating all
arguments that can be used by llvm_add_library and the macros it calls
(it also relies on implicit passing of some arguments to
llvm_process_sources).
Currently, an LLDB target option controls whether plugins report all
threads. However, it seems natural for this knowledge could come from
the plugin itself. To support this, this commits adds a virtual method
to the plugin base class, making the Python OS query the target option
to preserve existing behavior.
...and "[lldb/Interpreter] Introduce `ScriptedStopHook{,Python}Interface` & make use of it (#105449)"
This reverts commit 76b827bb4d5b4cc4d3229c4c6de2529e8b156810, and commit 1e131ddfa8f1d7b18c85c6e4079458be8b419421
because the first commit caused the test command-stop-hook-output.test to fail.
This patch introduces new `ScriptedStopHook{,Python}Interface` classes
that make use of the Scripted Interface infrastructure and makes use of
it in `StopHookScripted`.
It also relax the requirement on the number of argument for initializing
scripting extension if the size of the interface parameter pack contains
1 less element than the extension maximum number of positional arguments
for this initializer.
This addresses the cases where the embedded interpreter session
dictionary is passed to the extension initializer which is not used most
of the time.
---------
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch adds new requirements to the Scripted Interface abstract
method checker to check the minimum number of argument for abstract
methods.
This check is done when creating the interface object so the object is
not created if the user implementation doesn't match the abstract method
requirement.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch removes all of the Set.* methods from Status.
This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.
This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()
Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form
` ResultTy DoFoo(Status& error)
`
to
` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?
The interesting changes are in Status.h and Status.cpp, all other
changes are mostly
` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.
This patch tries to fix an issue with the windows debug builds where the
PDB file for python scripted interfaces cannot be opened since its path
length exceed the windows `MAX_PATH` limit:
https://github.com/llvm/llvm-project/pull/101672#issuecomment-2289481324
This patch addresses the issue by building all the interfaces as a
single library plugin that initiliazes each component as part of its
`Initialize` method, instead of building each interface as its own
library plugin.
This keeps the build artifact path length smaller while respecting the
naming convention and without making any exception in the build system.
Fixes#104895.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This reverts commit 9effefbae8d96006a4dd29bb9ab8532fd408559d.
With the include order in ScriptedProcessPythonInterface.cpp fixed
(though I cannot explain exactly why it works) and removes the /H flag
intended for debugging this issue.
I think it is something to do with Process.h pulling in PosixApi.h
somewhere along the line, and including Process.h after lldb-python.h
means that NO_PID_T is defined to prevent a redefinition of pid_t.
This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:
https://lab.llvm.org/buildbot/#/builders/141/builds/1175/
However this patch adds the `/H` compiler flag when building
the ScriptedProcessPythonInterface library to be able to investigate the
include order issue.
This patch will be revert after 1 failing run on the windows bot.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:
https://lab.llvm.org/buildbot/#/builders/141/builds/1175/
However this patch adds the `-H` compiler flag when building
the ScriptedProcessPythonInterface library to be able to investigate the
include order issue.
This patch will be revert after 1 failing run on the windows bot.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:
https://lab.llvm.org/buildbot/#/builders/141/builds/1175/
However this patch adds the `-H` & `-MM` compiler flags when building
the ScriptedProcessPythonInterface library to be able to investigate the
include order issue.
This patch will be revert after 1 failing run on the windows bot.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch is a follow-up to bccff3baeff8 which adds the
`ScriptedProcess` extension to the `scripting template list` command as
well as its description.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch is a follow-up to bccff3baeff8 which adds the
`OperatingSystem` extension to the `scripting template list` command as
well as its description.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch is a follow-up to bccff3baeff8 which adds the
`ScriptedPlatform` extension to the `scripting template list` command as
well as its description.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name suggests, this sub-command
operates on scripting templates, and currently has the ability to
automatically discover the various scripting extensions that lldb
supports.
This was previously reviewed in #97273.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
