[lldb-dev] RFC: Platform-independent remote debugging

[Michael Sartain]

I think this all sounds great Ashok.

> 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.

We use gdbserver with valgrind. Super useful, and being able to connect
with lldb would be fantastic.

Looking forward to all this for all the other reasons too. Thanks!
 -Mike

On Tue, Aug 27, 2013 at 1:46 PM, Thirumurthi, Ashok <
ashok.thirumurthi at intel.com> wrote:

>  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 at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130828/3911de21/attachment.html>