[all-commits] [llvm/llvm-project] 8ccfca: [lldb/platform-gdb] Clear cached protocol state up...
Pavel Labath via All-commits
all-commits at lists.llvm.org
Mon Jan 10 07:29:10 PST 2022
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 8ccfcab34ffb068f127e88be9fb1f42bb46f3af4
https://github.com/llvm/llvm-project/commit/8ccfcab34ffb068f127e88be9fb1f42bb46f3af4
Author: Pavel Labath <pavel at labath.sk>
Date: 2022-01-10 (Mon, 10 Jan 2022)
Changed paths:
M lldb/packages/Python/lldbsuite/test/lldbgdbclient.py
M lldb/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
M lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
M lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h
M lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
Log Message:
-----------
[lldb/platform-gdb] Clear cached protocol state upon disconnection
Previously we would persist the flags indicating whether the remote side
supports a particular feature across reconnects, which is obviously not
a good idea.
I implement the clearing by nuking (its the only way to be sure :) the
entire GDBRemoteCommunication object in the disconnect operation and
creating a new one upon connection. This allows us to maintain a nice
invariant that the GDBRemoteCommunication object (which is now a
pointer) exists only if it is connected. The downside to that is that a
lot of functions now needs to check the validity of the pointer instead
of blindly accessing the object.
The process communication does not suffer from the same issue because we
always destroy the entire Process object for a relaunch.
Differential Revision: https://reviews.llvm.org/D116539
More information about the All-commits
mailing list