### Summary
`SBModuleSpecList` already supports `len()` and iteration via `__len__`
and `__iter__`, but is not subscriptable — `specs[0]` raises
`TypeError`.
This adds a `__getitem__` method that supports integer indexing (with
negative index support) and string lookup using `endswith()` matching,
which works for both Unix and Windows paths.
### Supported key types
| Key type | Example | Behavior |
|---|---|---|
| `int` | `specs[0]`, `specs[-1]` | Direct index with negative index
support |
| `str` | `specs['a.out']`, `specs['/usr/lib/liba.dylib']` | Lookup by
basename or partial/full path via `endswith()`. Returns first match or
`None` |
### Error handling
- **`IndexError`** for out-of-bounds integer indices
- **`TypeError`** for unsupported key types (e.g., `float`)
- **`None`** for string lookups with no match
### Before
```python
>>> specs = lldb.SBModuleSpecList.GetModuleSpecifications('/bin/ls')
>>> specs[0]
Traceback (most recent call last):
File "<console>", line 1, in <module>
TypeError: 'SBModuleSpecList' object is not subscriptable
```
### After
```python
>>> import lldb, re
>>> specs = lldb.SBModuleSpecList.GetModuleSpecifications('/bin/ls')
>>> specs[0]
file = '/bin/ls', arch = x86_64-*-linux, uuid = 3CCC0D8A-..., object size = 140928
>>> specs[-1]
file = '/bin/ls', arch = x86_64-*-linux, uuid = 3CCC0D8A-..., object size = 140928
>>> specs['ls']
file = '/bin/ls', arch = x86_64-*-linux, uuid = 3CCC0D8A-..., object size = 140928
>>> specs[999]
IndexError: list index out of range
>>> specs[1.5]
TypeError: unsupported index type: <class 'float'>
```
### Test plan
Added test_module_spec_list_indexing to TestSBModule.py covering:
- Positive and negative integer indexing
- Out-of-bounds raises IndexError
- Unsupported key type raises TypeError
- String lookup by basename and full path (endswith() matching)
- Missing key returns None
```
bin/llvm-lit -sv lldb/test/API/python_api/sbmodule/TestSBModule.py
```
```
PASS: LLDB :: test_GetObjectName_dwarf (TestSBModule.SBModuleAPICase)
PASS: LLDB :: test_GetObjectName_dwo (TestSBModule.SBModuleAPICase)
PASS: LLDB :: test_module_spec_list_indexing_dwarf (TestSBModule.SBModuleAPICase)
PASS: LLDB :: test_module_spec_list_indexing_dwo (TestSBModule.SBModuleAPICase)
----------------------------------------------------------------------
Ran 12 tests in 1.854s
OK (skipped=6)
```
Co-authored-by: Piyush Jaiswal <piyushjais@meta.com>
LLDB automatically discovers, but doesn't automatically load, scripts in
the dSYM bundle. This is to prevent running untrusted code. Users can
choose to import the script manually or toggle a global setting to
override this policy. This isn't a great user experience: the former
quickly becomes tedious and the latter leads to decreased security.
This PR offers a middle ground that allows LLDB to automatically load
scripts from trusted dSYM bundles. Trusted here means that the bundle
was signed with a certificate trusted by the system. This can be a
locally created certificate (but not an ad-hoc certificate) or a
certificate from a trusted vendor.
Many tests have ad hoc forms of the launch & break steps done by
`lldbutil.run_to_source_breakpoint`. This changes some of those tests to
use `run_to_source_breakpoint` instead.
Assisted-by: claude
This test technically does not require libc++. The test binary mimics
libc++'s namespace layout to trigger some frame hiding logic in lldb,
but it does not require libc++ to function.
This is explicitly marked as a libc++ test and functionally tests the
formatter for a vector of enums. I put it in the generic directory
because there's no reason this couldn't work for other c++ stdlibs.
Additionally, this should be using the custom libc++ like the other
tests.
For whatever reason we ended up with register/register but the first
register just had the second register folder in it.
Move the files up one level so we have register/<test files>.
This PR is the tests for #138717. I have split it from implementation as
there is a lot of code, and the two don't really overlap. The tests are
checking what a user will see in LLDB, and only indirectly what happens
in lldb-server.
There are two types of tests, the first is register access tests. These
start in a given mode, where a mode is a combination of the streaming
mode on or off, ZA on or off, and a vector length.
For register access tests I have used two states:
* Streaming mode, ZA on, default vector length
* Non-streaming mode, ZA off, default vector length
(changing mode and vector length is tested in existing SVE+SME tests and
the expression tests I'm adding in this same PR)
The test program:
* Sets up the requested mode.
* Allocates a bunch of buffers for LLDB to write expected register
values to.
* Sets initial register values.
Then LLDB looks for those expected values. Assuming they are present, it
then writes a new set of values to the registers, and to the buffers
within the program. The program is then stepped, which runs an
in-process function to check that it now sees those register values. If
that function fails, we have a bug. If it does not, LLDB then checks for
the same values.
This process repeats for several registers. Hence the repeated calls to
check_register_values in the test program.
In this way we make sure that LLDB sends the correct values to ptrace by
validating them in process. Also that LLDB does not write other
registers in the process of writing one register. Which happened to me
several times during development.
The buffer writes are done with memory writes not expression evaluation
becuase at this stage we cannot trust that expressions work (the
expression tests will later prove that they do).
The second type of tests are expression state restoration tests. For
each combination of states we check that we can restore to a given state
if an expression takes us into the other state. This includes between
the same state, and adds an extra vector length to check expanding and
shrinking SVE buffers. This produces roughly 64 tests.
I have written them all as one test case in a loop because these take a
long time (~20 minutes on an FVP) and you almost always want it to fail
fast. When tracing is enabled you'll see the current states logged.
It's possible that we could skip some of these tests as being very
unlikely to ever happen, but in the spirit of
"There are Only Four Billion Floats–So Test Them All!" I think it is
simpler to enumerate every possible state change.
I have not added a test for executing an expression incompatible with
the current mode because this leads to SIGILL, which I know we already
handle. At this time LLDB makes no effort to make the expression
compatible with the current mode either.
Fixes an issue where attaching by program would fail if the program name
was a partial name (e.g. "foobar" instead of "/path/to/foobar").
We failed to create the target which caused the attach to fail. Now we
fallback to the dummy target and update to the real target after the
attach completes.
Here is an example launch configuration that fail:
```
{
"type": "lldb-dap",
"name": "Attach (wait)",
"request": "attach",
"program": "foobar",
"waitFor": true
},
```
This patch introduces `PlatformContext.getFullLibName` which returns the
full dylib name for any platform based on the base name of the dylib.
Example:
```
# Windows
PlatformContext.getFullLibName("Foo") -> "Foo.dll"
# Linux
PlatformContext.getFullLibName("Foo") -> "libFoo.so"
```
Updates the lldb python test suite to ensure we call dumpSessionInfo()
in the test result's stopTest() method. This will ensure that we get the
session info dumped for all tests, even those that don't have an
explicit call to dumpSessionInfo() in the test case.
Additionally, I updated the lldb-dap test case to mark the '-dap.log' as
a log file, which will be recorded in the test output on failure.
Here is an example test run with a failure:
```
PASS: LLDB (build/bin/clang-arm64) :: test_step (TestDAP_step.TestDAP_step)
FAIL: LLDB (build/bin/clang-arm64) :: test_step_over_inlined_function (TestDAP_step.TestDAP_step)
Log Files:
- build/lldb-test-build.noindex/tools/lldb-dap/step/TestDAP_step/Failure.log
- build/lldb-test-build.noindex/tools/lldb-dap/step/TestDAP_step/Failure-dap.log
======================================================================
FAIL: test_step_over_inlined_function (TestDAP_step.TestDAP_step)
Test stepping over when the program counter is in another file.
----------------------------------------------------------------------
Traceback (most recent call last):
File "llvm-project/lldb/test/API/tools/lldb-dap/step/TestDAP_step.py", line 113, in test_step_over_inlined_function
self.assertFalse(
AssertionError: True is not false : expect path ending with 'main.cpp'.
Config=arm64-build/bin/clang
----------------------------------------------------------------------
Ran 2 tests in 4.849s
```
This is flakey on the buildbot.
https://lab.llvm.org/buildbot/#/builders/141/builds/16719 as reported on
#188751.
```
FAIL: test_step_over_with_python_api_dwarf (TestInlineStepping.TestInlineStepping.test_step_over_with_python_api_dwarf)
Test stepping over and into inlined functions.
---------------------------------------------------------------------- Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2019, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\functionalities\inline-stepping\TestInlineStepping.py", line 25, in test_step_over_with_python_api
self.inline_stepping_step_over()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\functionalities\inline-stepping\TestInlineStepping.py", line 317, in inline_stepping_step_over
self.run_step_sequence(step_sequence)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\functionalities\inline-stepping\TestInlineStepping.py", line 152, in run_step_sequence
self.do_step(step_pattern[1], target_line_entry, test_stack_depth)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\functionalities\inline-stepping\TestInlineStepping.py", line 83, in do_step
self.fail(
AssertionError: Failed to stop due to step into operation stepping to: C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\functionalities\inline-stepping\calling.cpp:46
```
version, and clang will say it supports the flag even if the linker
can't use its output.
The compiler actually has code to know whether the linker version is
right, and sets it to the default if the stars align.
So I'm going to just test whether whatever is the default method for the
compiler and linker works.
On Darwin, clang added a new objc class method dispatch, turned on by
the flag: `-fobjc-msgsend-class-selector-stubs`. These stubs are like
the accelerated stubs added previously for method selectors. This patch
adds support for stepping through them.
I had previously handled the method stubs by figuring out the object ->
class and then used the selector encoded in the stub name. But that
depended on all the stubs setting the object into arg1 before calling
the stub, which not all the stubs do anymore. Since all the stubs do
some work and then call objc_msgSend, instead of trying to predict what
the stub is going to do, I just let it run to the objc_msgSend and then
figure out how to go from there - at that point arg1 and arg2 are
correctly set, so I can use the regular objc_msgSend trampoline for
that.
That change meant I was no longer using the "find the implementation"
method that was passing in the selector string that we pulled from the
stub name, so this patch also removes that.
These tests no longer fail on arm Linux after the frame provider
re-entrancy fixes, so remove the decorators.
XPASS: https://lab.llvm.org/buildbot/#/builders/18/builds/25348
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
The @expectedFailureAll decorators for Windows (llvm.org/pr24778) are no
longer needed on test_circular_dependency_handle_command_in_init and
test_provider_receives_parent_frames.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
When a scripted frame provider calls back into the thread's frame
machinery (e.g. via HandleCommand or EvaluateExpression), two problems
arise:
1. GetStackFrameList() re-enters the SyntheticStackFrameList
construction, causing infinite recursion.
2. ClearStackFrames() tries to read-lock the StackFrameList's
shared_mutex that is already write-locked by GetFramesUpTo,
causing a deadlock.
This patch fixes those issues by tracking when a provider is actively
fetching frames via a per-host-thread map (m_provider_frames_by_thread)
keyed by HostThread. The map is pushed/popped in
SyntheticStackFrameList::FetchFramesUpTo before calling into the
provider. GetStackFrameList() checks it to route re-entrant calls:
- The provider's own host thread gets the parent frame list, preventing
circular dependency when get_frame_at_index calls back into
GetFrameAtIndex.
- The private state thread also gets the parent frame list, preventing
deadlock when a provider calls EvaluateExpression (which needs the
private state thread to process events).
- Other host threads proceed normally and block on the frame list mutex
until the provider finishes, getting the correct synthetic result.
ClearStackFrames() returns early if any provider is active, since the
frame state is shared and tearing it down while a provider is
mid-construction is both unnecessary and unsafe.
rdar://171558394
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Change `self.build(...)` to assert if called with arguments of any kind,
for tests which have `SHARED_BUILD_TESTCASE` enabled (the default).
This also changes all tests that began asserting with this change, tests
which call `self.build(...)` with arguments.
---------
Co-authored-by: Adrian Prantl <adrian.prantl@gmail.com>
This patch exposes the `TypeSynthetic::SetFrontEndWantsDereference` via
the `type synthetic add` command.
The motivation for this is moving the various STL data-formatters to
Python. Those currently set this flag programmatically so that pointers
and references get formatted using the pointee synthetic provider.
Patch that makes use of this new option is:
https://github.com/llvm/llvm-project/pull/187677
Claude helped with writing the test code. Reviewed and cleaned it up
myself
When targeting arm64e, vtable pointers are signed with a discriminator
that incorporates the object's address
(PointerAuthVTPtrAddressDiscrimination) and class type
(PointerAuthVTPtrTypeDiscrimination).
I had to make a small change to clang, specifically in
getPointerAuthDeclDiscriminator(). Previously, that was computing the
discriminator based on getMangledName(). The latter returns the
AsmLabelAttr, which for functions imported by lldb, is prefixed with
`$__lldb_func`, causing a different discriminator to be generated.
Explicitly check whether we are building debugserver for arm64e. To
debug an arm64e binary, debugserver itself needs to be an arm64e
process.
This PR eliminates the possibility of configuring LLDB with Right now,
it's possible to configure CMake with
`LLDB_ENABLE_ARM64E_DEBUGSERVER=Off` and the decorator wouldn't account
for that.
When targeting arm64e, ISA pointers, class_ro_t pointers, and interface
selectors are signed in Objective-C. This PR adds support for that in
the expression evaluator.
When targeting arm64e, we enable `-fptrauth-indirect-gotos` by default,
which signs label addresses and authenticates indirect branches. Add
support (and a test) for this in the LLDB expression evaluator.
The initial version of SymbolLocatorSymStore supported servers only on
local paths. This patch extends it to HTTP/HTTPS end-points. For that to
work on Windows, we add a WinHTTP-based HTTP client backend in LLVM next
to the existing CURL-based implementation.
We don't add a HTTP server implementation, because there is no use right
now. Test coverage for the LLVM part is built on llvm-debuginfod-find
and works server-less, since it checks textual output of request
headers. The existing CURL-based implementation uses the same approach.
The LLDB API test for the specific SymbolLocatorSymStore feature spawns
a HTTP server from Python.
To keep the size of this patch within reasonable limits, the initial
implementation of the SymbolLocatorSymStore feature is dump: There is no
caching, no verification of downloaded files and no protection against
file corruptions. We use a local implementation of LLVM's
HTTPResponseHandler, but should think about extracting and reusing
Debuginfod's StreamedHTTPResponseHandler in the future.
The goal of this patch is a basic working implementation that is
testable in isolation. We will iterate on it to improve it further. This
should be fine since downloading from SymStores is not default-enabled
yet. Users have to set their server URLs explicitly.
---------
Co-authored-by: Alexandre Ganea <aganea@havenstudios.com>
This PR upstreams support for PtrAuth in the LLDB expression evaluator.
It's a rebased version of an older patch in the Swiftlang repo
(https://github.com/swiftlang/llvm-project/pull/5012) but adapted to not
rely on `GlobalPtrAuthInfo.h`. I followed Anton's advice, and instead of
iterating over all globals and hack on wrappers, the pass now iterates
over all global uses and fixes up ConstantPtrAuth expressions if any.
This is one of the last large chunks of downstream PtrAuth code in LLDB,
and the primary blocker for running the LLDB test suite in arm64e mode
on Apple Silicon, which I'd really like to make the default in the
future.
Fetch the size of the shared cache address range in VM in the inferior
process and return it, if possible. This allows for a simple call to
DynamicLoader::GetSharedCacheInformation to get the virtual address
extent of the shared cache in the inferior. It's a minor addition to the
method that fetches the shared cache filepath from the inferior, plus
piping it up through lldb's layers.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
While looking at the '[raw]' value of a std::vector I noticed we didn't
handle the anonymous inner struct very well. The 'evaluateName' was
incorrect (e.g. the evaluateName would return `<var>.` for the anonymous
struct).
This improves support for variables with anonymous fields and anonymous
types.
* Changed the name of anonymous fields from `<null>` to `(anonymous)`,
which matches other tooling like clangd's representation and how types
are presented if the field is not defined.
* Adjusts variables to not return an 'evaluateName' for anonymous
fields.
* Adjusted '[raw]' values to be marked as 'internal' which deemphasizes
them in the UI.
While working in this area, I also consolidated some helpers that are
only used within Variables.cpp.
Before my changes:
<img width="513" height="460" alt="before"
src="https://github.com/user-attachments/assets/3da0aada-8ba3-415d-bbec-56b41a9b9415"
/>
After my changes:
<img width="414" height="467" alt="after"
src="https://github.com/user-attachments/assets/66a47108-ee44-4e01-8eab-e89edb348fde"
/>
Fix and improve #187145 for following issues:
* Fix unhandled error.
* Align the log type with the file where it contains.
* The added test doesn't work on windows host for remote debugging, add
decorator to skip when host and target do not match.
Add a LoadCompilationPrefixMap() helper in SymbolFile::FindPlugin that
walks up from the symbol file's directory looking for a
compilation-prefix-map.json file. When found, each key→value entry is
applied to the module's source path mapping list, allowing LLDB to
resolve source file paths that were rewritten by -fdebug-prefix-map at
build time without requiring manual `settings set target.source-map`.
The JSON file format maps fake paths (as written into debug info) back
to their real on-disk counterparts:
{ "/fake/srcdir": "/real/srcdir" }
Directory results are cached so the filesystem is walked at most once
per unique directory across all modules loaded in a session.
Also apply the module's source path remappings in
SymbolFileDWARFDebugMap::ParseCompileUnitAtIndex when constructing
compile units from N_SO stabs. This mirrors what MakeAbsoluteAndRemap
does for the dSYM case so that fake paths baked into the debug map are
transparently resolved to real paths.
rdar://84824567
Assisted-By: Claude
`Make` uses systems's `mkdir` on Windows even if Git's mkdir.exe is
present in PATH. Windows's mkdir does not support the parameter `-p` and
creates the directory `-p` instead. Few other tests also use `mkdir -p`
but they are linux, objc or macosx related.
---------
Co-authored-by: Charles Zablit <c_zablit@apple.com>
Deleting anything in the build directory of a test-case is causing an
issue on one of the Windows bots. After the previous attempts in
ca15db1cd509c236cd8138bcd098117d0106db56 and
fdd2437af3cdc6d5fe199fcc9d991ccf503b55bd didn't help, we now skip the
file cleanup altogether.
Deleting the inferior binary after an API test-case causes issues on one
of the Windows bots. The previous the fix attempt in ca15db1cd509c236
didn't succeed. We have to use isolated subfolders for each test-case.
This is achieved easily by disabling SHARED_BUILD_TESTCASE.
This paths allows expressions in `setVariable` request. It is small
extension of original semantics from DAP specification. DAP has
`setExpression` request to this purpose, but it is too general. So I
prefer to keep this simple solution.
In #186001, I said the last large chunk of downstream PtrAuth code in
LLDB was the expression evaluator support. However, that wasn't
accurate, as we also have changes to thread this through ValueObject.
Deleting the executable at the end of this API test-case fails with a
permission error, likely because lldb still holds a reference to the
EXE. Exit explicitly to avoid that.
Minimal infrastructure for a the SymbolLocator plugin that fetches debug
info from Microsoft SymStore repositories. This can work cross-platform
and for various debug info formats in principle, but the current plan is
focussed on PE/COFF on Windows with debug info in PDB files. Once we
have a stable first version, we'd like to add features like download,
environment variables, caching and progress feedback for users.
SymbolVendorPECOFF was tailored towards DWARF debug info so far. I added
code to load the PDB path from the executable (it only checked
gnu_debuglink so far) and not bail out if DWARF sections are missing, so
that in the PDB case we still call AddSymbolFileRepresentation() in the
very end of CreateInstance().
The API test in this patch mocks the directory layout from SymStore, so
it doesn't depend on SymStore.exe from the Windows SDK. It runs on all
platforms that link debug info in a PDB file, which is still just
Windows, but it could be cross-platform in principle.
-----
Relands with minor fixes: API tests create mocked SymStore in the test's
build directory. One log instruction was moved. One more object
access goes through module in SymbolFile.
The [lldb-aarch64-windows](https://lab.llvm.org/buildbot/#/builders/141)
buildbot failed with:
```
lld-link: error: undefined symbol: printf
>>> referenced by main.o:(main)
```
I'm assuming that's because of the use of `__builtin_printf`. In other
tests, we use `printf` form `stdio.h` and these build fine, so I added
an include and used `printf`.
In PR#183176 there was a regression mixing up `GetSyntheticValue` and
`GetNonSyntheticValue` that results in `[raw]` variables not correctly
representing the underlying value.
Addressing this regression and adjusting the naming of a few helpers to
better match existing naming styles in lldb.
This patch extracts the `msg` value of the `failwithmessage` error and
uses it as the stop reason if the MSVC Runtime fails while debugging.
# Before
```
lldb.exe C:\Users\charleszablit\Developer\testing\uninit.exe -b -o 'r'
(lldb) target create "C:\\Users\\charleszablit\\Developer\\testing\\uninit.exe"
Current executable set to 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64).
(lldb) r
Process 9400 launched: 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64)
Process 9400 stopped
* thread #1, stop reason = Exception 0x80000003 encountered at address 0x7ff96516c96a
frame #0: 0x00007ff77efe20ba uninit.exe`failwithmessage(retaddr=0x00007ff77efe150f, crttype=1, errnum=3, msg="The variable 'x' is being used without being initialized.") at error.cpp:210
```
# After
```
lldb.exe C:\Users\charleszablit\Developer\testing\uninit.exe -b -o 'r'
(lldb) target create "C:\\Users\\charleszablit\\Developer\\testing\\uninit.exe"
Current executable set to 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64).
(lldb) r
Process 9400 launched: 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64)
Process 9400 stopped
* thread #1, stop reason = Run-time check failure: The variable 'x' is being used without being initialized.
frame #0: 0x00007ff77efe20ba uninit.exe`failwithmessage(retaddr=0x00007ff77efe150f, crttype=1, errnum=3, msg="The variable 'x' is being used without being initialized.") at error.cpp:210
```
fix https://github.com/llvm/llvm-project/issues/184990.
rdar://172103284
