Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# b1751faa 14-Jan-2025 David Spickett <david.spickett@linaro.org>

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


Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0
# 1b0a8024 04-Sep-2024 Felipe de Azevedo Piovezan <fpiovezan@apple.com>

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

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


Revision tags: llvmorg-19.1.0-rc4
# 8b4147d1 23-Aug-2024 Felipe de Azevedo Piovezan <fpiovezan@apple.com>

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


Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7
# 8917739b 04-Jun-2024 David Spickett <david.spickett@linaro.org>

[lldb][test] Disable MD5 test for old versions of Visual Studio (#94325)

In older versions there is this problem:

https://developercommunity.visualstudio.com/t/c-shared-state-futuresstate-default

[lldb][test] Disable MD5 test for old versions of Visual Studio (#94325)

In older versions there is this problem:

https://developercommunity.visualstudio.com/t/c-shared-state-futuresstate-default-constructs-the/60897

Which prevents us making a future out of a result type. There's
no good workaround so just don't compile this for older versions.

show more ...


Revision tags: llvmorg-18.1.6
# 95f208f9 09-May-2024 Anthony Ha <anthonyha96@gmail.com>

[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

![image](https://github.com/llvm/llvm-project/assets/1326275/b26859e2-18c3-4685-be8f-c6b6a5a4bc77)

1. Remote file differs

![image](https://github.com/llvm/llvm-project/assets/1326275/cbdb3c58-555a-401b-9444-c5ff4c04c491)

1. Remote file matches

![image](https://github.com/llvm/llvm-project/assets/1326275/07561572-22d1-4e0a-988f-bc91b5c2ffce)

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


Revision tags: llvmorg-18.1.5
# 22c26fa1 18-Apr-2024 Anthony Ha <anthonyha96@gmail.com>

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


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5
# f6938ffd 23-May-2023 Jie Fu <jiefu@tencent.com>

[lldb][test] Fix -Wsign-compare in GDBRemoteCommunicationClientTest.cpp (NFC)

/data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: error: comparison of integers of diffe

[lldb][test] Fix -Wsign-compare in GDBRemoteCommunicationClientTest.cpp (NFC)

/data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: error: comparison of integers of different signs: 'const int' and 'const unsigned long' [-Werror,-Wsign-compare]
if (lhs == rhs) {
~~~ ^ ~~~
/data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1553:12: note: in instantiation of function template specialization 'testing::internal::CmpHelperEQ<int, unsigned long>' requested here
return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs);
^
/data/llvm-project/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp:303:3: note: in instantiation of function template specialization 'testing::internal::EqHelper::Compare<int, unsigned long, nullptr>' requested here
ASSERT_EQ(10, num_packets);
^
/data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:2056:32: note: expanded from macro 'ASSERT_EQ'
^
/data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:2040:54: note: expanded from macro 'GTEST_ASSERT_EQ'
ASSERT_PRED_FORMAT2(::testing::internal::EqHelper::Compare, val1, val2)
^
1 error generated.

show more ...


# 1370a1cb 22-May-2023 Med Ismail Bennani <ismail@bennani.ma>

[lldb] Add support for negative integer to {SB,}StructuredData

This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for bo

[lldb] Add support for negative integer to {SB,}StructuredData

This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for both
`int64_t` & `uint64_t` with a public type aliases, respectively
`SignedInteger` & `UnsignedInteger`.

It adds new getter for signed and unsigned interger values to the
`StructuredData::Object` base class and changes the implementation of
`StructuredData::Array::GetItemAtIndexAsInteger` and
`StructuredData::Dictionary::GetValueForKeyAsInteger` to support signed
and unsigned integers.

This patch also adds 2 new `Get{Signed,Unsigned}IntegerValue` to the
`SBStructuredData` class and marks `GetIntegerValue` as deprecated.

Finally, this patch audits all the caller of `StructuredData::Integer`
or `StructuredData::GetIntegerValue` to use the proper type as well the
various tests that uses `SBStructuredData.GetIntegerValue`.

rdar://105575764

Differential Revision: https://reviews.llvm.org/D150485

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...


Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2
# 8bddb13c 17-Apr-2023 Alex Langford <alangford@apple.com>

[lldb] Change parameter type of StructuredData::ParseJSON

Instead of taking a `const std::string &` we can take an
`llvm::StringRef`. The motivation for this change is that many of the
callers of `P

[lldb] Change parameter type of StructuredData::ParseJSON

Instead of taking a `const std::string &` we can take an
`llvm::StringRef`. The motivation for this change is that many of the
callers of `ParseJSON` end up creating a temporary `std::string` from an existing
`StringRef` or `const char *` in order to satisfy the API. There's no
reason we need to do this.

Differential Revision: https://reviews.llvm.org/D148579

show more ...


Revision tags: llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# 2fe83274 07-Jan-2023 Kazu Hirata <kazu@google.com>

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


# f190ce62 07-Jan-2023 Kazu Hirata <kazu@google.com>

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optiona

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


# 9464bd8c 17-Dec-2022 Fangrui Song <i@maskray.me>

[lldb] llvm::Optional::value => operator*/operator->

std::optional::value() has undesired exception checking semantics and is
unavailable in some older Xcode. The call sites block std::optional migr

[lldb] llvm::Optional::value => operator*/operator->

std::optional::value() has undesired exception checking semantics and is
unavailable in some older Xcode. The call sites block std::optional migration.

show more ...


# d2a6114f 05-Dec-2022 Kazu Hirata <kazu@google.com>

[lldb/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the am

[lldb/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3
# 5ad6ed0e 19-Aug-2022 Jim Ingham <jingham@apple.com>

Change the meaning of a UUID with all zeros for data.

Previously, depending on how you constructed a UUID from data or a
StringRef, an input value of all zeros was valid (e.g. setFromData)
or not (e

Change the meaning of a UUID with all zeros for data.

Previously, depending on how you constructed a UUID from data or a
StringRef, an input value of all zeros was valid (e.g. setFromData)
or not (e.g. setFromOptionalData). Since there was no way to tell
which interpretation to use, it was done somewhat inconsistently.
This standardizes the meaning of a UUID of all zeros to Not Valid,
and removes all the Optional methods and their uses, as well as the
static factories that supported them.

Differential Revision: https://reviews.llvm.org/D132191

show more ...


Revision tags: llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# 5cff5142 16-Jul-2022 Kazu Hirata <kazu@google.com>

Use value instead of getValue (NFC)


# e5f568a4 13-Jul-2022 Kazu Hirata <kazu@google.com>

Use has_value instead of hasValue (NFC)


# 3b7c3a65 25-Jun-2022 Kazu Hirata <kazu@google.com>

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.


# aa8feeef 25-Jun-2022 Kazu Hirata <kazu@google.com>

Don't use Optional::hasValue (NFC)


Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3
# 555cd031 25-Jun-2021 David Spickett <david.spickett@linaro.org>

[lldb] Correct format of qMemTags type field

The type field is a signed integer.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)

However it's not packed in the packet

[lldb] Correct format of qMemTags type field

The type field is a signed integer.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)

However it's not packed in the packet in the way
you might think. For example the type -1 should be:
qMemTags:<addr>,<len>:ffffffff
Instead of:
qMemTags:<addr>,<len>:-1

This change makes lldb-server's parsing more strict
and adds more tests to check that we handle negative types
correctly in lldb and lldb-server.

We only support one tag type value at this point,
for AArch64 MTE, which is positive. So this doesn't change
any of those interactions. It just brings us in line with GDB.

Also check that the test target has MTE. Previously
we just checked that we were AArch64 with a toolchain
that supports MTE.

Finally, update the tag type check for QMemTags to use
the same conversion steps that qMemTags now does.
Using static_cast can invoke UB and though we do do a limit
check to avoid this, I think it's clearer with the new method.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D104914

show more ...


Revision tags: llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4
# 5ea091a8 31-Mar-2021 David Spickett <david.spickett@linaro.org>

[lldb][AArch64] Add memory tag writing to lldb

This adds memory tag writing to Process and the
GDB remote code. Supporting work for the
"memory tag write" command. (to follow)

Process WriteMemoryTa

[lldb][AArch64] Add memory tag writing to lldb

This adds memory tag writing to Process and the
GDB remote code. Supporting work for the
"memory tag write" command. (to follow)

Process WriteMemoryTags is similair to ReadMemoryTags.
It will pack the tags then call DoWriteMemoryTags.
That function will send the QMemTags packet to the gdb-remote.

The QMemTags packet follows the GDB specification in:
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets

Note that lldb-server will be treating partial writes as
complete failures. So lldb doesn't need to handle the partial
write case in any special way.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D105181

show more ...


# 3c326955 26-Jul-2021 Michał Górny <mgorny@moritz.systems>

[lldb] [gdb-remote client] Avoid zero padding PID/TID in H packet

Change SetCurrentThread*() logic not to include the zero padding
in PID/TID that was a side effect of 02ef0f5ab483. This should fix

[lldb] [gdb-remote client] Avoid zero padding PID/TID in H packet

Change SetCurrentThread*() logic not to include the zero padding
in PID/TID that was a side effect of 02ef0f5ab483. This should fix
problems caused by sending 64-bit integers to 32-bit servers. Reported
by Ted Woodward.

Differential Revision: https://reviews.llvm.org/D106832

show more ...


# 379f24ff 09-Jul-2021 Jim Ingham <jingham@apple.com>

Revert "Revert "Reset the wakeup timeout when we re-enter the continue wait.""

This reverts commit 82a38837150099288a1262391ef43e1fd69ffde4.

The original version had a copy-paste error: using the I

Revert "Revert "Reset the wakeup timeout when we re-enter the continue wait.""

This reverts commit 82a38837150099288a1262391ef43e1fd69ffde4.

The original version had a copy-paste error: using the Interrupt timeout
for the ResumeSynchronous wait, which is clearly wrong. This error would
have been evident with real use, but the interrupt is long enough that it
only caused one testsuite failure (in the Swift fork).

Anyway, I found that mistake and fixed it and checked all the other places
where I had to plumb through a timeout, and added a test with a short
interrupt timeout stepping over a function that takes 3x the interrupt timeout
to complete, so that should detect a similar mistake in the future.

show more ...


# 02ef0f5a 14-Apr-2021 Michał Górny <mgorny@moritz.systems>

[lldb] [gdb-remote client] Refactor SetCurrentThread*()

Refactor SetCurrentThread() and SetCurrentThreadForRun() to reduce code
duplication and simplify it. Both methods now call common
SendSetCurr

[lldb] [gdb-remote client] Refactor SetCurrentThread*()

Refactor SetCurrentThread() and SetCurrentThreadForRun() to reduce code
duplication and simplify it. Both methods now call common
SendSetCurrentThreadPacket() that implements the common protocol
exchange part (the only variable is sending `Hg` vs `Hc`) and returns
the selected TID. The logic is rewritten to use a StreamString
instead of snprintf().

A side effect of the change is that thread-id sent is now zero-padded.
However, this should not have practical impact on the server as both
forms are equivalent.

Differential Revision: https://reviews.llvm.org/D100459

show more ...


# 6e5c4a44 25-Jun-2021 David Spickett <david.spickett@linaro.org>

[lldb] Re-enable GDB server client memory tag read tests

These were disabled in 473a3a773ea565612e836ae6c2093178c5a9eb72
because they failed on 32 bit platforms. (Arm for sure but I assume
any 32 bi

[lldb] Re-enable GDB server client memory tag read tests

These were disabled in 473a3a773ea565612e836ae6c2093178c5a9eb72
because they failed on 32 bit platforms. (Arm for sure but I assume
any 32 bit)

This was due to the printf formatter used. These assumed
that types like uint64_t/size_t would be certain size/type and
that changes on 32 bit.

Instead use "z" to print the size_t and PRI<...> formatters
for the addr_t (always uint64_t) and the int32_t.

show more ...


# 473a3a77 24-Jun-2021 Muhammad Omair Javaid <omair.javaid@linaro.org>

Disable check_qmemtags unit tests

check_qmemtags tests are broken on Arm 32 bits. This patch disables
these tests.

Differential Revision: https://reviews.llvm.org/D95602


123