A large task remains to re-factor LLDB to generalize remote and native local debugging. This refactoring has been suggested by Greg Clayton and here I'm summarizing the rationale and the high-level refactoring for comment. There are a few goals:
* Platform-independent remote debugging. * Same source code for tasks common to native local and remote debugging (i.e. related to process, threads and registers). * Native local debugging that does not require packet preparation and parsing. The main goal is to ensure that the details of packet preparation and parsing don't affect native local debugging. This keeps debug logs simple and allows problems specific to packet handling to be diagnosed independently of generic issues. * Separation between the communication required to support gdb-server versus LLDB extensions. The main goal is to ensure a strict LLDB protocol when available while maintaining some level of support for the myriad of applications that implement the gdb-server protocol. So, the refactoring is aimed at replacing debugserver with a new binary that reuses functionality common to native local and remote debugging. Replacing debugserver is preferable since debugserver isn't platform independent and it is a mix of communication and process/thread/register smarts. In more detail: 1. New lldb-host library containing Host::Process and Host::Thread at the top level. This is a platform-independent service layer used for both native local and remote debugging. In general, the service layer implements basic tasks and assumes that the caller has already established a valid context for the operation. For instance, when enumerating the threads for a process, it assumes that a process attach has completed. For this reason, this is not intended to be a low-level debugger API for public consumption. a. Host::Process implements basic tasks like attach and thread enumeration. b. Host::Thread implements basic tasks like manipulating the thread state and uses Host::RegisterContext to manipulate the register set. c. This Host layer will delegate to platform-specific classes analogous to the POSIX ProcessMonitor. As a result, it will only maintain state when required for performance optimization. For instance, the register set could be cached to service queries as long as the current frame has not changed. d. The functionality of the Host layer is analogous to the 'C' interface in DNB.h used by debugserver. 2. New ProcessNative class derived from lldb::private::Process. This new Process plug-in will start off as a sibling for ProcessPOSIX but eventually replace derivatives of lldb_private::Process used for native local and remote debugging with a single ProcessNative class whose implementation is delegated to Host::Process. This stateful class will represent per-process context needed to implement the LLDB API. 3. New ThreadNative class derived from lldb::private::Thread. This new Thread plug-in will start off as a sibling for POSIXThread, but eventually replace derivatives of lldb_private::Thread that are used for native local and remote debugging with a single ThreadNative class whose implementation is delegated to Host::Thread. This stateful class will represent per-thread context needed to implement the LLDB API. 4. Improved GDBRemoteCommunicationServer class to implement the gdb-server protocol. This class, in development for lldb-platform, will be extended to handle as many packets as the current debugserver. For instance, packets related to the register set. This class will use the new lldb-host library to implement remote debugging. 5. New LLDBRemoteCommunicationServer class (derived from GDBRemoteCommunicationServer) to implement the extensions to the gdb-server protocol required by lldb (i.e. for multi-threaded debugging). The goal here is to maintain compatibility with applications that implement the gdb-server protocol with clear separation for extensions such as a proposed sequence number for packets (to avoid race conditions with asynchronous communications). The LLDBRemoteCommunicationServer will be a strict implementation of LLDB extensions to the gdb-server protocol. 6. Reuse the GDBRemoteCommunicationClient class to prepare and parse packets as required to implement the LLDB command set. Again, the LLDBRemoteCommunicationClient will derive from and delegate most of its work to GDBRemoteCommunicationClient. 7. New tools/lldb-server applet to eventually replace debugserver across platforms. This application will use LLDB/GDBRemoteCommunicationServer classes for communication and an API in development for platform discovery (future SBPlatform). Specifically, lldb-server can optionally use a platform API to simplify the remote launch, lldb-platform can be used independent of a debug target, and lldb-server will use the LLDB protocol (gdb-server protocol with extensions) by default. Since the new classes can be implemented without impacting the current functionality, we propose doing this work in trunk. Note that Greg's platform branch was recently merged. Cheers, - Ashok
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
