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

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