summaryrefslogtreecommitdiffstats
path: root/lldb/source/Utility/StringExtractor.cpp
diff options
context:
space:
mode:
authorPavel Labath <labath@google.com>2016-07-29 13:10:02 +0000
committerPavel Labath <labath@google.com>2016-07-29 13:10:02 +0000
commite768c4b858bd32b814baf142dd2acfeae6022638 (patch)
tree6dbc3506214dee86958ee5c3081ac1e881951e79 /lldb/source/Utility/StringExtractor.cpp
parentb37fb4d2cadb15c449e7a537e449bef1ea60f1b4 (diff)
downloadbcm5719-llvm-e768c4b858bd32b814baf142dd2acfeae6022638.tar.gz
bcm5719-llvm-e768c4b858bd32b814baf142dd2acfeae6022638.zip
Rewrite gdb-remote's SendContinuePacketAndWaitForResponse
SendContinuePacketAndWaitForResponse was huge function with very complex interactions with several other functions (SendAsyncSignal, SendInterrupt, SendPacket). This meant that making any changes to how packet sending functions and threads interact was very difficult and error-prone. This change does not add any functionality yet, it merely paves the way for future changes. In a follow-up, I plan to add the ability to have multiple query packets in flight (i.e., request,request,response,response instead of the usual request,response sequences) and use that to speed up qModuleInfo packet processing. Here, I introduce two special kinds of locks: ContinueLock, which is used by the continue thread, and Lock, which is used by everyone else. ContinueLock (atomically) sends a continue packet, and blocks any other async threads from accessing the connection. Other threads create an instance of the Lock object when they want to access the connection. This object, while in scope prevents the continue from being send. Optionally, it can also interrupt the process to gain access to the connection for async processing. Most of the syncrhonization logic is encapsulated within these two classes. Some of it still had to bleed over into the SendContinuePacketAndWaitForResponse, but the function is still much more manageable than before -- partly because of most of the work is done in the ContinueLock class, and partly because I have factored out a lot of the packet processing code separate functions (this also makes the functionality more easily testable). Most importantly, there is none of syncrhonization code in the async thread users -- as far as they are concerned, they just need to declare a Lock object, and they are good to go (SendPacketAndWaitForResponse is now a very thin wrapper around the NoLock version of the function, whereas previously it had over 100 lines of synchronization code). This will make my follow up changes there easy. I have written a number of unit tests for the new code and I have ran the test suite on linux and osx with no regressions. Subscribers: tberghammer Differential Revision: https://reviews.llvm.org/D22629 llvm-svn: 277139
Diffstat (limited to 'lldb/source/Utility/StringExtractor.cpp')
-rw-r--r--lldb/source/Utility/StringExtractor.cpp1
1 files changed, 1 insertions, 0 deletions
diff --git a/lldb/source/Utility/StringExtractor.cpp b/lldb/source/Utility/StringExtractor.cpp
index 4c0029a0649..e25acabfaf8 100644
--- a/lldb/source/Utility/StringExtractor.cpp
+++ b/lldb/source/Utility/StringExtractor.cpp
@@ -433,6 +433,7 @@ size_t
StringExtractor::GetHexByteString (std::string &str)
{
str.clear();
+ str.reserve(GetBytesLeft() / 2);
char ch;
while ((ch = GetHexU8()) != '\0')
str.append(1, ch);
OpenPOWER on IntegriCloud