[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