[lldb-dev] Target and platform clarification request

Matthew Gardiner mg11 at csr.com
Thu Jul 3 23:27:48 PDT 2014


Greg Clayton wrote:
>> 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
>
>
>
Thanks for this, Greg.

Matt


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.



More information about the lldb-dev mailing list