1ee03d1e09
## 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>
32 lines
1.1 KiB
ReStructuredText
32 lines
1.1 KiB
ReStructuredText
Python Reference
|
|
================
|
|
|
|
The entire LLDB API is available as Python functions through a script bridging
|
|
interface. This means the LLDB API's can be used directly from python either
|
|
interactively or to build python apps that provide debugger features.
|
|
|
|
Additionally, Python can be used as a programmatic interface within the lldb
|
|
command interpreter (we refer to this for brevity as the embedded interpreter).
|
|
Of course, in this context it has full access to the LLDB API - with some
|
|
additional conveniences we will call out in the FAQ.
|
|
|
|
Python Tutorials
|
|
-----------------
|
|
|
|
The following tutorials and documentation demonstrate various Python capabilities within LLDB:
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
tutorials/accessing-documentation
|
|
tutorials/python-embedded-interpreter
|
|
tutorials/script-driven-debugging
|
|
tutorials/breakpoint-triggered-scripts
|
|
tutorials/creating-custom-breakpoints
|
|
tutorials/automating-stepping-logic
|
|
tutorials/writing-custom-commands
|
|
tutorials/implementing-standalone-scripts
|
|
tutorials/custom-frame-recognizers
|
|
tutorials/extending-target-stop-hooks
|
|
tutorials/scripted-symbol-locator
|