mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2024-12-01 01:31:26 +00:00
8ccfcab34f
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 |
||
---|---|---|
.. | ||
lldbsuite |