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

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] Don't flush llvm::raw_string_ostream (NFC) (#110128)

Don't call raw_string_ostream::flush(), which is essentially a no-op. As
specified in the docs, raw_string_ostream is always unbuffered.

[lldb] Don't flush llvm::raw_string_ostream (NFC) (#110128)

Don't call raw_string_ostream::flush(), which is essentially a no-op. As
specified in the docs, raw_string_ostream is always unbuffered. (
65b13610a5226b84889b923bae884ba395ad084d for further reference )

show more ...

[lldb] Nits on uses of llvm::raw_string_ostream (NFC) (#108745)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610

[lldb] Nits on uses of llvm::raw_string_ostream (NFC) (#108745)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884ba395ad084d for further reference )

* Don't call raw_string_ostream::flush(), which is essentially a no-op.
* Avoid unneeded calls to raw_string_ostream::str(), to avoid excess
indirection.

show more ...

[NFC] Add explicit #include llvm-config.h where its macros are used, lldb part. (#107603)

(this is lldb part)

Without these explicit includes, removing other headers, who implicitly
include llvm

[NFC] Add explicit #include llvm-config.h where its macros are used, lldb part. (#107603)

(this is lldb part)

Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects. For example,
`clangd` may report even `llvm-config.h` as "no used" in case it defines
a macro, that is explicitly used with #ifdef. It is actually amplified
with different build configs which use different set of macros.

show more ...

[lldb] Make conversions from llvm::Error explicit with Status::FromEr… (#107163)

…ror() [NFC]

[GDBRemote] Handle 'heap' memory region info type (#105883)

This should cause the memory region info "is stack" field to be set to
"no".

[lldb] Turn lldb_private::Status into a value type. (#106163)

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
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

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.

show more ...

[GDBRemote] Fix processing of comma-separated memory region entries (#105873)

The existing algorithm was performing the following comparisons for an
`aaa,bbb,ccc,ddd`:

aaa\0bbb,ccc,ddd == "stack

[GDBRemote] Fix processing of comma-separated memory region entries (#105873)

The existing algorithm was performing the following comparisons for an
`aaa,bbb,ccc,ddd`:

aaa\0bbb,ccc,ddd == "stack"
aaa\0bbb\0ccc,ddd == "stack"
aaa\0bbb\0ccc\0ddd == "stack"

Which wouldn't work. This commit just dispatches to a known algorithm
implementation.

show more ...

[lldb] Claim to support swbreak and hwbreak packets when debugging a gdbremote (#102873)

This fixes https://github.com/llvm/llvm-project/issues/56125 and
https://github.com/vadimcn/codelldb/issues/

[lldb] Claim to support swbreak and hwbreak packets when debugging a gdbremote (#102873)

This fixes https://github.com/llvm/llvm-project/issues/56125 and
https://github.com/vadimcn/codelldb/issues/666, as well as the
downstream issue in our binary ninja debugger:
https://github.com/Vector35/debugger/issues/535

Basically, lldb does not claim to support the `swbreak` packet so the
gdbserver would not use it. As a result, the gdbserver always sends the
unmodified program counter value which, on systems like x86, causes the
program counter to be off-by-one (or otherwise wrong). For reference,
the lldb-server always sends the modified program counter value so it
works perfectly with lldb.

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Stop-Reply-Packets.html#swbreak-stop-reason

No new code is added to add support `swbreak`, since the way lldb works
already expects the remote to have adjusted the program counter. The
change just lets the gdbserver know that lldb supports it, so that it
will send the adjusted program counter.

To test this PR, you can use lldb to connect to a gdbserver running on
e.g., Ubuntu 22.04, and see the program counter is off-by-one without
the patch. With the patch, things work as expected

show more ...

[lldb] Use operator==(StringRef, StringRef) instead of StringRef::equals (NFC) (#92476)

Note that StringRef::equals has been deprecated in favor of
operator==(StringRef, StringRef).

[lldb] Unify CalculateMD5 return types (#91029)

This is a retake of https://github.com/llvm/llvm-project/pull/90921
which got reverted because I forgot to modify the CalculateMD5 unit test
I had a

[lldb] Unify CalculateMD5 return types (#91029)

This is a retake of https://github.com/llvm/llvm-project/pull/90921
which got reverted because I forgot to modify the CalculateMD5 unit test
I had added in https://github.com/llvm/llvm-project/pull/88812

The prior failing build is here:
https://lab.llvm.org/buildbot/#/builders/68/builds/73622
To make sure this error doesn't happen, I ran `ninja
ProcessGdbRemoteTests` and then executed the resulting test binary and
observed the `CalculateMD5` test passed.

# Overview
In my previous PR: https://github.com/llvm/llvm-project/pull/88812,
@JDevlieghere suggested to match return types of the various calculate
md5 functions.

This PR achieves that by changing the various calculate md5 functions to
return `llvm::ErrorOr<llvm::MD5::MD5Result>`.
 
The suggestion was to go for `std::optional<>` but I opted for
`llvm::ErrorOr<>` because local calculate md5 was already possibly
returning `ErrorOr`.

To make sure I didn't break the md5 calculation functionality, I ran
some tests for the gdb remote client, and things seem to work.

# Testing
1. Remote file doesn't exist


1. Remote file differs


1. Remote file matches


## Test gaps
Unfortunately, I had to modify
`lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I
can't test the changes there. Hopefully, the existing test suite / code
review from whomever is reading this will catch any issues.

show more ...

Revert "[lldb] Unify CalculateMD5 return types" (#90998)

Reverts llvm/llvm-project#90921

[lldb] Unify CalculateMD5 return types (#90921)

# Overview
In my previous PR: https://github.com/llvm/llvm-project/pull/88812,
@JDevlieghere suggested to match return types of the various calculat

[lldb] Unify CalculateMD5 return types (#90921)

# Overview
In my previous PR: https://github.com/llvm/llvm-project/pull/88812,
@JDevlieghere suggested to match return types of the various calculate
md5 functions.

This PR achieves that by changing the various calculate md5 functions to
return `llvm::ErrorOr<llvm::MD5::MD5Result>`.
 
The suggestion was to go for `std::optional<>` but I opted for
`llvm::ErrorOr<>` because local calculate md5 was already possibly
returning `ErrorOr`.

To make sure I didn't break the md5 calculation functionality, I ran
some tests for the gdb remote client, and things seem to work.

# Testing
1. Remote file doesn't exist


1. Remote file differs


1. Remote file matches


## Test gaps
Unfortunately, I had to modify
`lldb/source/Plugins/Platform/MacOSX/PlatformDarwinDevice.cpp` and I
can't test the changes there. Hopefully, the existing test suite / code
review from whomever is reading this will catch any issues.

Co-authored-by: Anthony Ha <antha@microsoft.com>

show more ...

[lldb] Skip remote PutFile when MD5 hashes equal (#88812)

This PR adds a check within `PutFile` to exit early when both local and
destination files have matching MD5 hashes. If they differ, or ther

[lldb] Skip remote PutFile when MD5 hashes equal (#88812)

This PR adds a check within `PutFile` to exit early when both local and
destination files have matching MD5 hashes. If they differ, or there is
trouble getting the hashes, the regular code path to put the file is
run.

As I needed this to talk to an `lldb-server` which runs the gdb-remote
protocol, I enabled `CalculateMD5` within `Platform/gdb-server` and also
found and fixed a parsing bug within it as well. Before this PR, the
client is incorrectly parsing the response packet containing the
checksum; after this PR, hopefully this is fixed. There is a test for
the parsing behavior included in this PR.

---------

Co-authored-by: Anthony Ha <antha@microsoft.com>

show more ...

Aim debugserver workaround more precisely. (#83099)

[lldb] Add QSupported key to report watchpoint types supported (#80376)

debugserver on arm64 devices can manage both Byte Address Select
watchpoints (1-8 bytes) and MASK watchpoints (8 bytes-2 giga

[lldb] Add QSupported key to report watchpoint types supported (#80376)

debugserver on arm64 devices can manage both Byte Address Select
watchpoints (1-8 bytes) and MASK watchpoints (8 bytes-2 gigabytes). This
adds a SupportedWatchpointTypes key to the QSupported response from
debugserver with a list of these, so lldb can take full advantage of
them when creating larger regions with a single hardware watchpoint.

Also add documentation for this, and two other lldb extensions, to the
lldb-gdb-remote.txt documentation.

Re-enable TestLargeWatchpoint.py on Darwin systems when testing with the
in-tree built debugserver. I can remove the "in-tree built debugserver"
in the future when this new key is handled by an Xcode debugserver.

show more ...

[lldb] Upstream xros support in lldb (#78389)

Upstream support for debugging xros applications through LLDB.

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[lldb] Change interface of StructuredData::Array::GetItemAtIndexAsDictionary (#71961)

Similar to my previous patch (#71613) where I changed
`GetItemAtIndexAsString`, this patch makes the same chang

[lldb] Change interface of StructuredData::Array::GetItemAtIndexAsDictionary (#71961)

Similar to my previous patch (#71613) where I changed
`GetItemAtIndexAsString`, this patch makes the same change to
`GetItemAtIndexAsDictionary`.

`GetItemAtIndexAsDictionary` now returns a std::optional that is either
`std::nullopt` or is a valid pointer. Therefore, if the optional is
populated, we consider the pointer to always be valid (i.e. no need to
check pointer validity).

show more ...