Revert "[lldb] Implement basic support for reverse-continue" (#123906)

Reverts llvm/llvm-project#112079 due to failures on the arm bot.

[lldb] Implement basic support for reverse-continue (#112079)

This commit adds support for a
`SBProcess::ContinueInDirection()` API. A user-accessible command for
this will follow in a later commit.

[lldb] Implement basic support for reverse-continue (#112079)

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.

show more ...

[lldb][Linux] Mark memory regions used for shadow stacks (#117861)

This is intended for use with Arm's Guarded Control Stack extension
(GCS). Which reuses some existing shadow stack support in Linu

[lldb][Linux] Mark memory regions used for shadow stacks (#117861)

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.

show more ...

[LLDB][LoongArch] Add LSX and LASX register definitions and operations

With this patch, vector registers can be read and written when debugging a live process.

Note: We currently assume that all Lo

[LLDB][LoongArch] Add LSX and LASX register definitions and operations

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

show more ...

[lldb] fix fd leak during lldb testsuite (#118093)

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

[lldb] fix fd leak during lldb testsuite (#118093)

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.

show more ...

Revert "[lldb] Implement basic support for reverse-continue (#99736)"

Reverting this again; I added a commit which added @skipIfDarwin
markers to the TestReverseContinueBreakpoints.py and
TestRevers

Revert "[lldb] Implement basic support for reverse-continue (#99736)"

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.

show more ...

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later com

[lldb] Implement basic support for reverse-continue (#99736)

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).

show more ...

Revert "[lldb] Implement basic support for reverse-continue (#99736)"

This reverts commit d5e1de6da96c1ab3b8cae68447e8ed3696a7006e.

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later com

[lldb] Implement basic support for reverse-continue (#99736)

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).

show more ...

[lldb] Fix minor runCmd error message formatting (#110150)

This tweaks the construction of the error message when using `expect`/`runCmd`. With
this change, the stdout/stderr is placed after the me

[lldb] Fix minor runCmd error message formatting (#110150)

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>
```

show more ...

[lldb][AArch64][Linux] Add Floating Point Mode Register (#106695)

Otherwise known as FEAT_FPMR. This register controls the behaviour of
floating point operations.

https://developer.arm.com/docum

[lldb][AArch64][Linux] Add Floating Point Mode Register (#106695)

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.

show more ...

[lldb][test] Handle failure to get /proc/cpuinfo from a remote Linux platform (#108183)

I've been testing against qemu-aarch64 using the qemu-user platform,
which doesn't support get-file:
```
As

[lldb][test] Handle failure to get /proc/cpuinfo from a remote Linux platform (#108183)

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
(https://gitlab.com/qemu-project/qemu/-/commit/a55b9e72267085957cadb0af0a8811cfbd7c61a9)
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.

show more ...

[NFC] Prefer subprocess.DEVNULL over os.devnull (#106500)

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

[NFC] Prefer subprocess.DEVNULL over os.devnull (#106500)

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.

show more ...

[lldb][test] Fix TestMultipleDebuggers test on non-x86, other small issues (#101169)

This test has been flaky lately
(https://github.com/llvm/llvm-project/issues/101162) and I disabled it
everywhe

[lldb][test] Fix TestMultipleDebuggers test on non-x86, other small issues (#101169)

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.

show more ...

[lldb] Remove python helper getCompilerBinary() (#100660)

This causes a number of tests be `UNRESOLVED` on Windows if
`getCompiler()` has a space in the name, because `getCompilerBinary()`
uncondi

[lldb] Remove python helper getCompilerBinary() (#100660)

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>

show more ...

[lldb] fix(lldb/**.py): fix comparison to None (#94017)

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):

> Comparisons to singletons like None should always be done wit

[lldb] fix(lldb/**.py): fix comparison to None (#94017)

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):

> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.

Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>

show more ...

[lldb] fix(lldb/**.py): fix comparison to True/False (#94039)

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):

> Comparisons to singletons like None should always be do

[lldb] fix(lldb/**.py): fix comparison to True/False (#94039)

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):

> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.

Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>

show more ...

[lldb] Move TestBase.runCmd() to the Base class (#92252)

runCmd() is called from Base.getCPUInfo() but implemented only in
TestBase(Base). Usually it works if TestBase is used. But call
getCPUInfo

[lldb] Move TestBase.runCmd() to the Base class (#92252)

runCmd() is called from Base.getCPUInfo() but implemented only in
TestBase(Base). Usually it works if TestBase is used. But call
getCPUInfo() from a class based on Base will cause something like
```
File "E:\projects\llvm-nino\lldb\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1256, in getCPUInfo
self.runCmd('platform get-file "/proc/cpuinfo" ' + cpuinfo_path)
AttributeError: 'TestGdbRemoteExpeditedRegisters' object has no attribute 'runCmd'
```
BTW, TestBase.setUp() called runCmd() before applying
LLDB_MAX_LAUNCH_COUNT and LLDB_TIME_WAIT_NEXT_LAUNCH.

This patch fixes the test TestGdbRemoteExpeditedRegisters in case of
Windows host and Linux target.

show more ...

[lldb] Fixed SyntaxWarning invalid escape sequence '\l' in lldbtest.py (#90609)

Add a new SBExpressionOptions::SetLanguage() API (NFCI) (#89981)

that separates out language and version. To avoid reinventing the wheel
and introducing subtle incompatibilities, this API uses the

Add a new SBExpressionOptions::SetLanguage() API (NFCI) (#89981)

that separates out language and version. To avoid reinventing the wheel
and introducing subtle incompatibilities, this API uses the table of
languages and versiond defined by the upcoming DWARF 6 standard
(https://dwarfstd.org/languages-v6.html). While the DWARF 6 spec is not
finialized, the list of languages is broadly considered stable.

The primary motivation for this is to allow the Swift language plugin to
switch between language dialects between, e.g., Swift 5.9 and 6.0 with
out introducing a ton of new language codes. On the main branch this
change is considered NFC.

Depends on https://github.com/llvm/llvm-project/pull/89980

show more ...

[libc++][CI] Tests LLDB libc++ data formatters. (#88312)

This enables testing of the LLDB libc++ specific data formatters.
This is enabled in the bootstrap build since building LLDB requires
Clang

[libc++][CI] Tests LLDB libc++ data formatters. (#88312)

This enables testing of the LLDB libc++ specific data formatters.
This is enabled in the bootstrap build since building LLDB requires
Clang and this
is quite expensive. Adding this test changes the build time from 31 to
34 minutes.

show more ...

[lldb][test][Windows] Don't assert that module cache is empty

For whatever reason on Windows, it is not at this point.

The copy of unit test we used to use would ignore failures during
teardown but

[lldb][test][Windows] Don't assert that module cache is empty

For whatever reason on Windows, it is not at this point.

The copy of unit test we used to use would ignore failures during
teardown but Python's does not.

show more ...

[lldb] Don't overwrite the dynamic loader library path for "driver tests"

We have a handful of tests that build a driver which links against LLDB.
When running those binaries, we overwrite the dynam

[lldb] Don't overwrite the dynamic loader library path for "driver tests"

We have a handful of tests that build a driver which links against LLDB.
When running those binaries, we overwrite the dynamic loader library
path to point to the build directory's libs dir, presumably to make sure
we load LLDB from there.

This above becomes an issue when you have libc++ enabled and the driver
is linked against the system's libc++, but the dynamic loader flag
forces it to pick up libc++ from the libs dir.

We could try to make the logic for building the driver smarter and have
it pick up the just-built libc++ like we do for our test binaries, but I
don't think we need to overwrite the library path in the first place.
The build logic to build these drivers already takes care to set the
correct RPATH in the linker.

This patch removes the logic and simplifies the tests.

show more ...

[lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (#79945)

This removes the dependency LLDB API tests have on
lldb/third_party/Python/module/unittest2, and instead uses the sta

[lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (#79945)

This removes the dependency LLDB API tests have on
lldb/third_party/Python/module/unittest2, and instead uses the standard
one provided by Python.

This does not actually remove the vendored dep yet, nor update the docs.
I'll do both those once this sticks.

Non-trivial changes to call out:
- expected failures (i.e. "bugnumber") don't have a reason anymore, so
those params were removed
- `assertItemsEqual` is now called `assertCountEqual`
- When a test is marked xfail, our copy of unittest2 considers failures
during teardown to be OK, but modern unittest does not. See
TestThreadLocal.py. (Very likely could be a real bug/leak).
- Our copy of unittest2 was patched to print all test results, even ones
that don't happen, e.g. `(5 passes, 0 failures, 1 errors, 0 skipped,
...)`, but standard unittest prints a terser message that omits test
result types that didn't happen, e.g. `OK (skipped=1)`. Our lit
integration parses this stderr and needs to be updated w/ that
expectation.

I tested this w/ `ninja check-lldb-api` on Linux. There's a good chance
non-Linux tests have similar quirks, but I'm not able to uncover those.

show more ...

[lldb] Remove obsolete signBinary helper (#79656)

On Darwin, the Makefile already (ad-hoc) signs everything it builds.
There's also no need to use lldb_codesign for this.