diff options
author | Pavel Labath <labath@google.com> | 2016-08-25 08:34:57 +0000 |
---|---|---|
committer | Pavel Labath <labath@google.com> | 2016-08-25 08:34:57 +0000 |
commit | 0faf37333c8bf7eaca3500c7d79c7fb99112caa5 (patch) | |
tree | 4ed0654fdfd3d54bf74b110cfc86e910192ad71a /lldb/packages/Python/lldbsuite/test/python_api/frame/TestFrames.py | |
parent | c1566308aa7596efad6d3ddc852eb3b443748309 (diff) | |
download | bcm5719-llvm-0faf37333c8bf7eaca3500c7d79c7fb99112caa5.tar.gz bcm5719-llvm-0faf37333c8bf7eaca3500c7d79c7fb99112caa5.zip |
gdb-remote: Make the sequence mutex non-recursive
Summary:
This is a preparatory commit for D22914, where I'd like to replace this mutex by an R/W lock
(which is also not recursive). This required a couple of changes:
- The only caller of Read/WriteRegister, GDBRemoteRegisterContext class, was already acquiring
the mutex, so these functions do not need to. All functions which now do not take a lock, take
an lock argument instead, to remind the caller of this fact.
- GetThreadSuffixSupported() was being called from locked and unlocked contexts (including
contexts where the process was running, and the call would fail if it did not have the result
cached). I have split this into two functions, one which computes the thread suffix support and
caches it (this one always takes the lock), and another, which returns the cached value (and
never needs to take the lock). This feels quite natural as ProcessGdbRemote was already
pre-caching this value at the start.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23802
llvm-svn: 279725
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/frame/TestFrames.py')
0 files changed, 0 insertions, 0 deletions