This commit adds support for a
`SBProcess::ContinueInDirection()` API. A user-accessible command for
this will follow in a later commit.
This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. For testing
purposes, this commit adds a Python implementation of *very limited*
record-and-reverse-execute functionality, implemented as a proxy between
lldb and lldb-server in `lldbreverse.py`. This should not (and in
practice cannot) be used for anything except testing.
The tests here are quite minimal but we test that simple breakpoints and
watchpoints work as expected during reverse execution, and that
conditional breakpoints and watchpoints work when the condition calls a
function that must be executed in the forward direction.
This is intended for use with Arm's Guarded Control Stack extension
(GCS). Which reuses some existing shadow stack support in Linux. It
should also work with the x86 equivalent.
A "ss" flag is added to the "VmFlags" line of shadow stack memory
regions in `/proc/<pid>/smaps`. To keep the naming generic I've called
it shadow stack instead of guarded control stack.
Also the wording is "shadow stack: yes" because the shadow stack region
is just where it's stored. It's enabled for the whole process or it
isn't. As opposed to memory tagging which can be enabled per region, so
"memory tagging: enabled" fits better for that.
I've added a test case that is also intended to be the start of a set of
tests for GCS. This should help me avoid duplicating the inline assembly
needed.
Note that no special compiler support is needed for the test. However,
for the intial enabling of GCS (assuming the libc isn't doing it) we do
need to use an inline assembly version of prctl.
This is because as soon as you enable GCS, all returns are checked
against the GCS. If the GCS is empty, the program will fault. In other
words, you can never return from the function that enabled GCS, unless
you push values onto it (which is possible but not needed here).
So you cannot use the libc's prctl wrapper for this reason. You can use
that wrapper for anything else, as we do to check if GCS is enabled.
With this patch, vector registers can be read and written when debugging a live process.
Note: We currently assume that all LoongArch64 processors include the
LSX and LASX extensions.
To add test cases, the following modifications were also made:
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/packages/Python/lldbsuite/test/make/Makefile.rules
Reviewed By: DavidSpickett, SixWeining
Pull Request: https://github.com/llvm/llvm-project/pull/120664
The Intel Darwin CI bots had their Xcode updated, which brought in a
debugserver with Brendan Shanks' change from September
7281e0cb3bbcce396aab8b3ea0967d7a17cd287a
https://github.com/llvm/llvm-project/pull/108663 where four general
purpose registers are sent by debugserver when in certain process
states. But most processes (nearly all in the testsuite) do not have
these registers available, so we will get register read failures when
requesting those four. These two tests would flag those as errors. There
would have been an additional problem with the g/G packet (which lldb
doesn't use w/ debugserver, but the testsuite tests) if placeholder
values were not included in the full register context bytes; I fixed
that issue with the SME patch to debugserver recently already.
Reduced MAX_ATTEMPTS to 10.
The sleep time will be 3, 3.6, 4.3, ..., 13, 15.
The total sleep time is 78 + 0.5 * MAX_CONNECT_ATTEMPTS * MAX_ATTEMPTS = 128.
Note the timeout is 600, so the rest time must be enough.
Increased the port range (12000..20000).
During lldb testing dotest.py opens files to dump testcase results, but
doesn't close them.
This patch makes necessary changes to fix the file descriptors leak.
This commit adds support for column breakpoints to lldb-dap.
To do so, support for the `breakpointLocations` request was
added. To find all available breakpoint positions, we iterate over
the line table.
The `setBreakpoints` request already forwarded the column correctly to
`SBTarget::BreakpointCreateByLocation`. However, `SourceBreakpointMap`
did not keep track of multiple breakpoints in the same line. To do so,
the `SourceBreakpointMap` is now indexed by line+column instead of by
line only.
See http://jonasdevlieghere.com/post/lldb-column-breakpoints/ for a
high-level introduction to column breakpoints.
The tests were using the variable directly to get the dwarf version used
for the test. That's only the overridden value, and won't be set if
we're using the compiler default. I also put a comment by the variable
to make sure people don't make the same mistake in the future.
More context can be found in
https://github.com/llvm/llvm-project/pull/110303
For DAP tests running in constrained environments (e.g., Docker
containers), disabling ASLR isn't allowed. So we set `disableASLR=False`
(since https://github.com/llvm/llvm-project/pull/113593).
However, the `dap_server.py` will currently only forward the value
of `disableASLR` to the DAP executable if it's set to `True`. If the
DAP executable wasn't provided a `disableASLR` field it defaults to
`true` too:
f147437945/lldb/tools/lldb-dap/lldb-dap.cpp (L2103-L2104)
This means that passing `disableASLR=False` from the tests is currently
not possible.
This is also true for many of the other boolean arguments of
`request_launch`. But this patch only addresses `disableASLR` for now
since it's blocking a libc++ patch.
When running in constrained environments like docker, disabling ASLR
might fail with errors like:
```
AssertionError: False is not true : launch failed (Cannot launch
'/__w/.../lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.test_subtleFrames/a.out':
personality set failed: Operation not permitted)
```
E.g., https://github.com/llvm/llvm-project/pull/110303
Hence we already run `settings set target.disable-aslr false` as part of
the init-commands for the non-DAP tests (see
https://github.com/llvm/llvm-project/pull/88312 and
https://discourse.llvm.org/t/running-lldb-in-a-container/76801).
But we never adjusted it for the DAP tests. As a result we get
conflicting test logs like:
```
{
"arguments": {
"commandEscapePrefix": null,
"disableASLR": true,
....
"initCommands": [
...
"settings set target.disable-aslr false",
```
Disabling ASLR by default in tests isn't useulf (it's only really a
debugging aid for users). So this patch sets `disableASLR=False` by
default.
Got caught out by this because simply specifying `DYLIB_CXX_SOURCES`
(without specifying `DYLIB_NAME`) resulted in linker errors because the
dylib was never built (and linked). We should probably make that a
Makefile error (though I haven't audited when exactly not specifying
`DYLIB_NAME` is valid; looked like that can happen when we specify
`FRAMEWORK`).
Reverting this again; I added a commit which added @skipIfDarwin
markers to the TestReverseContinueBreakpoints.py and
TestReverseContinueNotSupported.py API tests, which use lldb-server
in gdbserver mode which does not work on Darwin. But the aarch64 ubuntu
bot reported a failure on TestReverseContinueBreakpoints.py,
https://lab.llvm.org/buildbot/#/builders/59/builds/6397
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py", line 63, in test_reverse_continue_skip_breakpoint
self.reverse_continue_skip_breakpoint_internal(async_mode=False)
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py", line 81, in reverse_continue_skip_breakpoint_internal
self.expect(
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2372, in expect
self.runCmd(
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1002, in runCmd
self.assertTrue(self.res.Succeeded(), msg + output)
AssertionError: False is not true : Process should be stopped due to history boundary
Error output:
error: Process must be launched.
This reverts commit 4f297566b3150097de26c6a23a987d2bd5fc19c5.
This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later commit.
This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. So, for testing
purposes, `lldbreverse.py` wraps `lldb-server` with a Python
implementation of *very limited* record-and-replay functionality for use
by *tests only*.
The majority of this PR is test infrastructure (about 700 of the 950
lines added).
This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later commit.
This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. So, for testing
purposes, `lldbreverse.py` wraps `lldb-server` with a Python
implementation of *very limited* record-and-replay functionality for use
by *tests only*.
The majority of this PR is test infrastructure (about 700 of the 950
lines added).
This makes tests more portable.
Make variables for LLVM utils are passed to `make` on Darwin as well.
Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>
Many LLDB's dotest.py based tests require the `make` tool. If it's not found in Path, they fail with an obscure error and show up as `UNRESOLVED`. On Windows, llvm-lit takes care of MSYS based testing tools like cat, printf, etc., but `make` is not part of that. Let's catch the situation early and check for it at configuration time.
This error isn't fatal: It should fail the build, but not immediately stop the configuration process. There might be other issues further down the line that can be caught in the same buildbot run.
In aea066849, API tests were supposed to use LLVM tools.
However, a path to a utility is made up incorrectly there: util name
should be prefixed with `llvm-`.
Hence, it's fixed here.
Relands https://github.com/llvm/llvm-project/pull/108375 which had to be
reverted because it was failing on the Windows buildbot. Trying to
reland this with `msvc::no_unique_address` on Windows.
This commit improves the auto-completion in the Debug Console provided
by VS-Code.
So far, we were always suggesting completions for both LLDB commands and
for variables / expressions, even if the heuristic already determined
how the given string will be executed, e.g., because the user explicitly
typed the escape prefix. Furthermore, auto-completion after the escape
character was broken, since the offsets were not adjusted correctly.
With this commit we now correctly take this into account.
Even with this commit, auto-completion does not always work reliably:
* VS Code only requests auto-completion after typing the first
alphabetic character, but not after punctuation characters. This means
that no completions are provided after typing "`"
* LLDB does not provide autocompletions if a string is an exact match.
This means if a user types `l` (which is a valid command), LLDB will not
provide "language" and "log" as potential completions. Even worse, VS
Code caches the completion and does client-side filtering. Hence, even
after typing `la`, no auto-completion for "language" is shown in the UI.
Those issues might be fixed in follow-up commits. Also with those known
issues, the experience is already much better with this commit.
Furthermore, I updated the README since I noticed that it was slightly
inaccurate.
This tweaks the construction of the error message when using `expect`/`runCmd`. With
this change, the stdout/stderr is placed after the message "Command '<command>' did not
return successfully".
Before:
```
AssertionError: False is not True : Command 'p whatever
Error output:
error: <some error message>
' did not return successfully
```
After:
```
AssertionError: False is not True : Command 'p whatever' did not return successfully
Error output:
error: <some error message>
```
In #102185, toolchain detection for API tests has been rewritten in
Python. Tools paths for tests there are determined from compiler path.
Here tools are taken from `--llvm-tools-dir` dotest.py argument, which
by default refers to the LLVM build directory, unless they are
explicitly redefined in environment variables. It helps to minimize
external dependencies and to maximize the reproducibility of the build.
Otherwise known as FEAT_FPMR. This register controls the behaviour of
floating point operations.
https://developer.arm.com/documentation/ddi0601/2024-06/AArch64-Registers/FPMR--Floating-point-Mode-Register
As the current floating point register contexts are fixed size, this has
been placed in a new set. Linux kernel patches have landed already, so
you can cross check with those.
To simplify testing we're not going to do any floating point operations,
just read and write from the program and debugger to make sure each sees
the other's values correctly.
## Purpose
Running the LLDB API tests against a remote Android target with NDK
version r22 or later fails to compile the test inferiors. NDK r21 from
2021 is the most recent NDK that still works with the LLDB API tests.
This PR updates the Android make rules to support newer Android NDK
versions (r19 and later).
## Overview
* Updates and simplifies `Android.rules` to match the newer Android NDK
unified toolchain layout introduced in NDK r19
* Sets `OBJCOPY` and `ARCHIVER` env vars, required by a few test cases,
to their `llvm-` versions in the unified toolchain
* Drops support for pre-2019 Android NDK versions to keep the rules
simple
* Provides an error message if the tests are run using an incompatible
NDK layout
## Problem Details
Android introduced a unified tools layout in NDK r19 (2019) and removed
the old layout in r22 (2021). Releases r19, r20, and r21 support both
the old and new layout side-by-side. More details are in #106270.
## Validation
Ran a sub-set of the LLDB API tests against remote Android targets for
the four primary architectures i386, x86_64, arm, and aarch64. No
validation was done against riscv targets.
For each case, ran the copy of `lldb-server` from the Android NDK on the
device with the latest LLDB test cases in llvm-project
Ran tests with both r19 (the oldest supported) and r26 (more recent,
unified layout only) NDK versions.
Example test command for aarch64:
```
./build/bin/lldb-dotest --out-of-tree-debugserver --arch aarch64 --platform-name remote-android --platform-url connect://localhost:5432 --platform-working-dir /data/local/tmp --compiler=$ANDROID_NDK_ROOT/toolchains/llvm/prebuilt/linux-x86_64/bin/clang lldb/test/API/android/
```
**NOTE: there are a lot of test failures when running the full suite
(especially against 32-bit ARM target). These failures occur independent
of this change.**
Verified the expected error message appears when attempting to run using
NDK r18
```
Build Command Output:
make: Entering directory '/home/andrew/src/llvm/llvm-project/build/lldb-test-build.noindex/android/platform/TestDefaultCacheLineSize.test_cache_line_size'
/home/andrew/src/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/make/Android.rules:16: *** "No unified toolchain sysroot found in /home/andrew/Android/Sdk/ndk/18.1.5063045/toolchains/llvm/prebuilt/linux-x86_64/bin/../../../../... NDK must be r19 or later.". Stop.
make: Leaving directory '/home/andrew/src/llvm/llvm-project/build/lldb-test-build.noindex/android/platform/TestDefaultCacheLineSize.test_cache_line_size'
```
## Impact
**This change explicitly removes support for the pre-2019 NDK
structure.** Only NDK r19 (from 2019) and later can be used when running
the LLDB API tests. If the maintainers object, we can easily support
both the old and new NDK toolchain layouts side-by-side at the cost of
readability/maintainability. Since this change only impacts tests, I
don't see much value in supporting NDKs that are over 5 years old.
## Guidance to Reviewers
* I am not an expert on `clang` arguments so if anything looks off let
me know.
* While I personally thing supporting 5+ year old NDKs for testing seems
unnecessary, please chime-in if you are concerned with dropping that
support. I can easily revise to support both old and new layouts
side-by-side.
* If there are any specific tests you'd like me to run I will do my best
to accommodate. It doesn't look like there's much (any?) Android LLDB CI
coverage.
The `enable` prefix is a filler word which adds no additional
information. Rename the setting to `displayExtendedBacktrace`
Given that this setting was only introduced a month ago, and that there
has not been any release since then, I assume that usage is still rather
low. As such, it should be fine to not provide backwards-compatibility
workarounds.
This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug adapter
protocol.
For the `declarationLocationReference` we need a variable ID similar to
the `variablesReference`. I decided to simply reuse the
`variablesReference` here and renamed `Variables::expandable_variables`
and friends accordingly. Given that almost all variables have a
declaration location, we now assign those variable ids to all variables.
While `declarationLocationReference` effectively supersedes
`$__lldb_extensions.declaration`, I did not remove this extension, yet,
since I assume that there are some closed-source extensions which rely
on it.
I tested this against VS-Code Insiders. However, VS-Code Insiders
currently only supports `valueLoctionReference` and not
`declarationLocationReference`, yet. Locally, I hence published the
declaration locations as value locations, and VS Code Insiders navigated
to the expected places. Looking forward to proper VS Code support for
`declarationLocationReference`.
Add support for the `readMemory` request which allows VS-Code to
inspect memory. Also, add `memoryReference` to variables and `evaluate`
responses, such that the binary view can be opened from the variables
view and from the "watch" pane.
These benchmarks don't get run as part of the regular API test-suite.
And I'm not aware of any CI running this. Also, I haven't quite managed
to actually run them locally using the `bench.py` script. It looks like
these are obsolete, so I'm proposing to remove the infrastructure around
it entirely.
If anyone does know of a use for these do let me know.
If multiple breakpoints are hit at the same time, multiple stop reasons
are reported, one per breakpoint.
Currently, `get_threads_stopped_at_breakpoint_id` only checks the first
such reason.
I've been testing against qemu-aarch64 using the qemu-user platform,
which doesn't support get-file:
```
AssertionError: False is not true : Command 'platform get-file "/proc/cpuinfo" <...>/TestAArch64LinuxMTEMemoryRegion.test_mte_regions/cpuinfo
Command output:
get-file failed: unimplemented
' did not return successfully
```
QEMU itself does support overriding cpuinfo for the emulated process
(a55b9e7226)
however we'd need to be able to read the cpuinfo before the process
starts, so I'm not attempting to use this feature.
Instead if the get-file fails, assume empty cpuinfo so we can at least
carry on testing. I've logged the failure and the reason to the trace so
developers can find it.
```
runCmd: platform get-file "/proc/cpuinfo" <...>/TestAArch64LinuxMTEMemoryRegion.test_mte_regions/cpuinfo
check of return status not required
runCmd failed!
Failed to get /proc/cpuinfo from remote: "get-file failed: unimplemented"
All cpuinfo feature checks will fail.
```
For now this only helps AArch64 but I suspect that RISC-V, being even
more mix and match when it comes to extensions, may need this in future.
And I know we have some folks testing against qemu-riscv at the moment.
This fix is based on a problem with cxx_compiler and cxx_linker macros
on Windows.
There was an issue with compiler detection in paths containing "icc". In
such case, Makefile.rules thought it was provided with icc compiler.
To solve that, utilities detection has been rewritten in Python.
The last element of compiler's path is separated, taking into account
the platform path delimiter, and compiler type is extracted, with regard
of possible cross-toolchain prefix.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
Refactoring `stackTrace` to perform frame look ups in a more on-demand
fashion to improve overall performance.
Additionally adding additional information to the `exceptionInfo`
request to report exception stacks there instead of merging the
exception stack into the stack trace. The `exceptionInfo` request is
only called if a stop event occurs with `reason='exception'`, which
should mitigate the performance of `SBThread::GetCurrentException`
calls.
Adding unit tests for exception handling and stack trace supporting.
There is no need to support Python 2.7 anymore, Python 3.3+ has
`subprocess.DEVNULL`. This is good practice and also prevents file
handles from
staying open unnecessarily.
Also remove a couple unused or unneeded `__future__` imports.
Added support for "supportsInstructionBreakpoints" capability and now it
this command is triggered when we set instruction breakpoint.
We need this support as part of enabling disassembly view debugging.
Following features should work as part of this feature enablement:
1. Settings breakpoints in disassembly view: Unsetting the breakpoint is
not happening from the disassembly view. Currently we need to unset
breakpoint manually from the breakpoint List. Multiple breakpoints are
getting set for the same $
2. Step over, step into, continue in the disassembly view
The format for DisassembleRequest and DisassembleResponse at
https://raw.githubusercontent.com/microsoft/vscode/master/src/vs/workbench/contrib/debug/common/debugProtocol.d.ts
.
Ref Images:
Set instruction breakpoint in disassembly view:
After issuing continue:
---------
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-hyd.qualcomm.com>
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-lv.qualcomm.com>
Previously, when output like `"hello\nworld\n"` was produced by lldb (or
the process) the message would be sent as a single Output event. By
being a single event this causes VS Code to treat this as a single
message in the console when handling displaying and filtering in the
Debug Console.
Instead, with these changes we send each line as its own event. This
results in VS Code representing each line of output from lldb-dap as an
individual output message.
Resolves#105444
VS Code requests the `instruction` stepping granularity if the assembly
view is currently focused. By implementing `StepGranularity`, we can
hence properly single-step through assembly code.
We only need to see that 1 frame of the stack is in user code. No need
to carry on looking.
Doing so actually caused a test failure on Armv8 Ubuntu Jammy where
a libc function does not have a display name. I'm sure I'm going to
get stung by this elsewhere, but for this test, breaking early
sidesteps the problem.
@walter-erquinigo found the the [PR with testing and a fix for
DebugInfoD](https://github.com/llvm/llvm-project/pull/98344) caused an
issue when working with stripped binaries.
The issue is that when you're working with split-dwarf, there are *3*
possible files: The stripped binary the user is debugging, the
"only-keep-debug" *or* unstripped binary, plus the `.dwp` file. The
debuginfod plugin should provide the unstripped/OKD binary. However, if
the debuginfod plugin fails, the default symbol locator plugin will just
return the stripped binary, which doesn't help. So, to address that, the
SymbolVendorELF code checks to see if the SymbolLocator's
ExecutableObjectFile request returned the same file, and bails if that's
the case. You can see the specific diff as the second commit in the PR.
I'm investigating adding a test: I can't quite get a simple repro, and
I'm unwilling to make any additional changes to Makefile.rules to this
diff, for Pavlovian reasons.
These changes aim to support cross-compilation build on Windows host for
Linux target for API tests execution. They're not final: changes will
follow for refactoring and adjustments to make all tests pass.
Chocolatey make is recommended to be used since it is maintained better
than GnuWin32 mentioned here
https://lldb.llvm.org/resources/build.html#windows (latest GnuWin32
release is dated by 2010) and helps to avoid problems with building
tests (for example, GnuWin32 make doesn't support long paths and there
are some other failures with building for Linux with it).
Co-authored-by: Pavel Labath <pavel@labath.sk>
This test has been flaky lately
(https://github.com/llvm/llvm-project/issues/101162) and I disabled it
everywhere initially.
I found that it always uses "x86_64" for the program architecture so the
test was "passing" elsewhere but I don't think it was meant to. So I
have added a define to pass on the host's architecture when compiling.
This makes it work on AArch64 as well.
While I'm here I've fixed the uint64_t formatting warnings by using the
defined formats that'll work everywhere.
In addition, I found that the function names include "()" on Linux, so
now we check for "foo" or "foo()".
The test cpp file has never been, or was only partially formatted so
I've not formatted the changes, just kept to the local style.
I've removed the Linux skip to see if any of this helps the timeouts,
and to verify the build command changes. If the timeouts come back I'll
disable it again.
This causes a number of tests be `UNRESOLVED` on Windows if
`getCompiler()` has a space in the name, because `getCompilerBinary()`
unconditionally splits on whitespace and returns the first result, which
might just be`"C:\Program"` if using a compiler such as `clang-cl` `cl`
from the absolute path to Visual studio's installation directory.
Co-authored-by: kendal <kendal@thebrowser.company>
## Issue
Attempting to run the lldb API tests against a remote-android target
fails with the error `NameError: name 'urlparse' is not defined`.
## Root Cause
It looks the Python import of `urlparse` was removed by mistake in
22ea97d7bfd65abf68a68b13bf96ad69be23df54. This import is only used when
running the lldb API tests against a remote-android target so it went
unnoticed.
## Fix
This change simply puts back the missing import. It is a one line
change.
fixes#99931
## Validation
Tested on Fedora 39 with an attached Android device:
`cd llvm-project`
`cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS='clang;lldb'
-DCMAKE_BUILD_TYPE=Release -DLLDB_ENABLE_PYTHON=On`
`ninja -C build`
`./build/bin/lldb-dotest --arch aarch64 --out-of-tree-debugserver
--platform-name=remote-android
--platform-working-dir=/data/local/tmp/ds2
--platform-url=connect://localhost:5432 --compiler
~/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/clang`
