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.
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
