[lldb-dev] Target and platform clarification request

[Greg Clayton]

> As an example, presumably it's possible to be debugging a remote FreeBSD process (which is being controlled by a gdbserver running on a remote FreeBSD box) from lldb running on a local linux box. In that case would the:
> 
> local platform = remote-freebsd
> remote platform = remote-gdb-server
> 
> with the local platform being -freebsd since the ELF being debugged was built for FreeBSD?

Yes the flow for this would current be to launch the remote gdb server:

remote.com% lldb-gdbserver host.com:1234 -- /bin/ls -lAF

Then start up LLDB on the host and debug to it

host.com% lldb
(lldb) target select remote-freebsd
(lldb) file /path/to/local/freebsd/build/a.out
(lldb) gdb-remote remote.com:1234

Selecting the platform first has a few benefits:
1 - if the "a.out" has dependent shared libraries like "/usr/lib/libfoo.so", the remote-freebsd platform might say "that file is in /usr/local/freebsd/sdk/9.0/usr/lib/libfoo.so". This would repeat for all shared libraries and you can do a "image list" and see all of the shared libraries you depend on and set breakpoint and inspect prior to running.
2 - platforms support some architectures and they can help select the right architecture in the /path/to/local/freebsd/build/a.out if there are more than 1 (not typical for ELF files currently, usually there is only 1 architecture in each file)


If you are connected to a remote platform, that connection could allow you download any needed files (like shared libraries) and have them cached locally:

remote.com% lldb-platform host.com:2000

(lldb) target select remote-freebsd
(lldb) platform connect connect://remote.com:2000
(lldb) file /path/to/local/freebsd/build/a.out
(lldb) run

When connected to a platform and if we are trying to track down dependencies for the "a.out" we could copy "libfoo.so" from remote.com:/usr/lib/libfoo.so" to a local cache directory.

So the connection to the platform is only required if you need to do dynamic things through the platform like list processes, and attach to an existing process, or run. In the above case, the lldb-platform would launch its own lldb-gdbserver for you and you would ever need to start the lldb-gdbserver on the remote machine. Or we can do things manually like the first case I showed where we start lldb-gdbserver ourselves and use "gdb-remote" to attach to it without the need for a live platform connection.

Greg