summaryrefslogtreecommitdiff
path: root/lldb/source/Core/ThreadedCommunication.cpp
AgeCommit message (Collapse)Author
2024-09-05[lldb] Make conversions from llvm::Error explicit with Status::FromEr… ↵Adrian Prantl
(#107163) …ror() [NFC]
2024-08-27[lldb] Turn lldb_private::Status into a value type. (#106163)Adrian Prantl
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.
2024-04-24[lldb][nfc] Move broadcaster class strings away from ConstString (#89690)Alex Langford
These are hardcoded strings that are already present in the data section of the binary, no need to immediately place them in the ConstString StringPools. Lots of code still calls `GetBroadcasterClass` and places the return value into a ConstString. Changing that would be a good follow-up. Additionally, calls to these functions are still wrapped in ConstStrings at the SBAPI layer. This is because we must guarantee the lifetime of all strings handed out publicly.
2023-08-15Revert "[lldb] Properly protect the Communication class with reader/writer lock"Augusto Noronha
This reverts commit 5d16957207ce1bd1a2091f3677e176012009c59a.
2023-08-15[lldb] Properly protect the Communication class with reader/writer lockAugusto Noronha
This patch picks up where https://reviews.llvm.org/D157159 left of, but allows for concurrent reads/writes, but protects setting up and tearing down the underlying Connection object. Differential Revision: https://reviews.llvm.org/D157760
2023-08-09[lldb] Fix data race in ThreadedCommunicationJonas Devlieghere
TSan reports the following race: Write of size 8 at 0x000107707ee8 by main thread: #0 lldb_private::ThreadedCommunication::StartReadThread(...) ThreadedCommunication.cpp:175 #1 lldb_private::Process::SetSTDIOFileDescriptor(...) Process.cpp:4533 #2 lldb_private::Platform::DebugProcess(...) Platform.cpp:1121 #3 lldb_private::PlatformDarwin::DebugProcess(...) PlatformDarwin.cpp:711 #4 lldb_private::Target::Launch(...) Target.cpp:3235 #5 CommandObjectProcessLaunch::DoExecute(...) CommandObjectProcess.cpp:256 #6 lldb_private::CommandObjectParsed::Execute(...) CommandObject.cpp:751 #7 lldb_private::CommandInterpreter::HandleCommand(...) CommandInterpreter.cpp:2054 Previous read of size 8 at 0x000107707ee8 by thread T5: #0 lldb_private::HostThread::IsJoinable(...) const HostThread.cpp:30 #1 lldb_private::ThreadedCommunication::StopReadThread(...) ThreadedCommunication.cpp:192 #2 lldb_private::Process::ShouldBroadcastEvent(...) Process.cpp:3420 #3 lldb_private::Process::HandlePrivateEvent(...) Process.cpp:3728 #4 lldb_private::Process::RunPrivateStateThread(...) Process.cpp:3914 #5 std::__1::__function::__func<lldb_private::Process::StartPrivateStateThread(...) function.h:356 #6 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(...) HostNativeThreadBase.cpp:62 #7 lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(...) HostThreadMacOSX.mm:18 The problem is the lack of synchronization between starting and stopping the read thread. This patch fixes that by protecting those operations with a mutex. Differential revision: https://reviews.llvm.org/D157361
2023-07-05[lldb] Fix incorrect uses of formatv specifiers in LLDB_LOGJonas Devlieghere
Fix incorrect uses of formatv specifiers in LLDB_LOG. Unlike Python, arguments must be numbered. All the affected log statements take llvm:Errors so use the LLDB_LOG_ERROR macro instead. Differential revision: https://reviews.llvm.org/D154532
2023-06-07[lldb][NFCI] Change type of Broadcaster's nameAlex Langford
Broadcasters don't need their names in the StringPool. It doesn't benefit from fast comparisons and doesn't benefit from uniqueness. Differential Revision: https://reviews.llvm.org/D152220
2022-12-10Don't include None.h (NFC)Kazu Hirata
I've converted all known uses of None to std::nullopt, so we no longer need to include None.h. 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
2022-12-04[lldb] Use std::nullopt instead of None (NFC)Kazu Hirata
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
2022-09-09[lldb] Fix ThreadedCommunication racesPavel Labath
The Read function could end up blocking if data (or EOF) arrived just as it was about to start waiting for the events. This was only discovered now, because we did not have unit tests for this functionality before. We need to check for data *after* we start listening for incoming events. There were no changes to the read thread code needed, as we already use this pattern in SynchronizeWithReadThread, so I just updated the comments to make it clear that it is used for reading as well. Differential Revision: https://reviews.llvm.org/D133410
2022-09-06[lldb] [Core] Split read thread support into ThreadedCommunicationMichał Górny
Split the read thread support from Communication into a dedicated ThreadedCommunication subclass. The read thread support is used only by a subset of Communication consumers, and it adds a lot of complexity to the base class. Furthermore, having a dedicated subclass makes it clear whether a particular consumer needs to account for the possibility of read thread being running or not. The modules currently calling `StartReadThread()` are updated to use `ThreadedCommunication`. The remaining modules use the simplified `Communication` class. `SBCommunication` is changed to use `ThreadedCommunication` in order to avoid changing the public API. `CommunicationKDP` is updated in order to (hopefully) compile with the new code. However, I do not have a Darwin box to test it, so I've limited the changes to the bare minimum. `GDBRemoteCommunication` is updated to become a `Broadcaster` directly. Since it does not inherit from `ThreadedCommunication`, its event support no longer collides with the one used for read thread and can be implemented cleanly. The support for `eBroadcastBitReadThreadDidExit` is removed from the code -- since the read thread was not used, this event was never reported. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.llvm.org/D133251