+
+ While the process of actual debugging (stepping, backtraces, evaluating
+ expressions) is same as in the local case, in the case of remote debugging, more
+ preparation is needed as the required binaries cannot started on the remote system
+ automatically. Also, if the remote system runs a different OS or architecture, the
+ server component needs to be compiled separately.
+
+
+
Remote system
+
+ On Linux and Android, all required remote functionality is contained in the
+ lldb-server binary. This binary combines the functionality of the
+ platform and gdb-remote stub. A single binary fascilitates deployment and reduces
+ code size, since the two functions share a lot of code. The
+ lldb-server binary is also statically linked with the rest of LLDB
+ (unlike lldb, which dynamically links to liblldb.so by
+ default), so it does not have any dependencies on the rest of lldb. On Mac OSX and
+ iOS, the remote-gdb functionality is implemented by the debugserver
+ binary, which you will need to deploy alongside lldb-server.
+
+
+
+ The binaries mentioned above need to be present on the remote system to enable
+ remote debugging. You can either compile on the remote system directly or copy them
+ from the local machine. If compiling locally and the remote architecture differs
+ from the local one, you will need to cross-compile the correct version of the binaries.
+ More information on cross-compiling LLDB can be found on the
+ build page.
+
+
+
+ Once the binaries are in place, you just need to run the lldb-server
+ in platform mode and specify the port it should listen on. For example, the command
+
+
lldb-server platform --listen *:1234
+
+ will start the LLDB platform and wait for incoming connections from any address to
+ port 1234. Specifying an address instead of * will only allow
+ connections originating from that address. Adding a --server parameter
+ to the command line will fork off a new process for every incoming connection,
+ allowing multiple parallel debug sessions.
+
+
+
Local system
+
+
+ On the local system, you need to let LLDB know that you intend to do remote
+ debugging. This is achieved through the platform command and its
+ sub-commands. As a first step you need to choose the correct platform plug-in for
+ your remote system. A list of available plug-ins can be obtained through
+ platform list.
+
+
+
+ The default platform is the platform host which is used for local
+ debugging. Apart from this, the list should contain a number of plug-ins, for
+ debugging different kinds of systems. The remote plug-ins are prefixed with
+ "remote-". For example, to debug a remote Linux application, you should
+ run platform select remote-linux.
+
+
+
+ After selecting the platform plug-in, you should receive a prompt which confirms
+ the selected platform, and states that you are not connected. This is because
+ remote plug-ins need to be connected to their remote platform counterpart to
+ operate. This is achieved using the platform connect command. This
+ command takes a number of arguments (as always, use the help command
+ to find out more), but normally you only need to specify the address to connect to,
+ e.g.:
+
+
platform connect connect://host:port
+
+
+ After this, you should be able to debug normally. You can use the
+ process attach to attach to an existing remote process or
+ target create, process launch to start a new one. The
+ platform plugin will transparently take care of uploading or downloading the
+ executable in order to be able to debug. If your application needs additional
+ files, you can transfer them using the platform commands: get-file,
+ put-file, mkdir, etc. The environment can be prepared
+ further using the platform shell command.
+
+
+