Yes it can, but work is definitely needed. Linux to OSX will work because we
have the lldb modified "debugserver" binary which can debug macosx apps. There
is no linux equivalent because the current "debugserver" binary was initially
made for the Mac only and it isn't well orgnanized to be used as a starting
point for porting to other systems.
What I would like see happen, is in our Host layer (in "lldb/source/Host" and
"lldb/include/lldb/Host"), we should have a native debug API that is very
closely based on "lldb/tools/debugserver/source/DNB.h" and name it something
like "lldb_private::NativeDebug". Once we do this, we can then support native
debugging on every platform by making a new Process plugin in
"lldb/source/Plugins/Process" called "Host" which would link against the new
API in the lldb_private::NativeDebug. We then also have classes which implement
remote GDB debugging inside lldb:
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
The "GDBRemoteCommunicationClient" class communicates with remote GDB servers.
The "GDBRemoteCommunicationServer" class implements the GDB server side of the
connection. This is not currently being used in "debugserver". This
"GDBRemoteCommunicationServer" class can then just link against the
"lldb_private::NativeDebug" class to implement remote debugging. This way, both
native and remote debugging always share the same base code.
There will need to be some work done on the build as well to make sure that all
plug-ins needed for remote debugging get linked in. Right now there is code
that disables many plug-ins when they shouldn't be disabled in
"lldb/source/lldb.cpp" by using proprocessor directives.
As for trying out remote debugging from linux, the flow would be to first
launch debugserver on the mac side:
darwin% debugserver linux.foo.com:12345 -- /bin/ls -lAF
Then launch lldb and connect on linux:
linux% lldb
(lldb) platform select --sysroot /remote/path/to/macosx/root remote-macosx
(lldb) file --arch x86_64 /remote/path/to/macosx/root/bin/ls
(lldb) process connect connect://darwin.foo.com:12345
...
We also have code in LLDB that manages platforms. We see above we switched
platforms from the default "localhost" platform to the "remote-macosx" platform
above. When we get platforms working, the flow will change to this:
darwin% lldb-platform linux.foo.com:12345
Now we have a platform on our macosx machine that can answer many things:
linux% lldb
(lldb) platform select remote-macosx
(lldb) platform connect connect://darwin.foo.com:12345
(lldb) platform process list
PID PARENT USER ARCH NAME
====== ====== ========== ======= ============================
16773 164 gclayton 6 x86_64-apple-macosx mdworker
16712 16711 gclayton 6 x86_64-apple-macosx tcsh
16709 164 gclayton 6 x86_64-apple-macosx Terminal
16705 164 gclayton 6 x86_64-apple-macosx mdworker
16668 1 gclayton 6 x86_64-apple-macosx XType.FontHelper
16652 1 gclayton 4 i386-apple-macosx qtkittrustedmoviesservice
16651 1 gclayton 4 i386-apple-macosx com.apple.qtkitserver
16649 164 gclayton 6 x86_64-apple-macosx WebKitPluginAgent
...
(lldb) platform process info 16712
Process information for process 16712:
pid = 16712
parent = 16711
name = tcsh
file = /bin/tcsh
arg[0] = -tcsh
arch = x86_64-apple-macosx
uid = 501 (gclayton)
...
Now we have an actual connection to a remote platform and we can ask the
platform launch a process for us:
(lldb) platform process launch -- /bin/ls -lAF
The platforms will be able to upload/download files, install new applications,
locate remote copies of platform files on the current computer, and much more.
We havea lot of that work started in our platform branch:
svn co http://llvm.org/svn/llvm-project/lldb/branches/lldb-platform-work
lldb-platform
We have had time to finish it all up, but we did get started. The Xcode project
for the MacOSX has a "lldb-platform" binary started that uses the GDB remote
protocol to implement the communication between computers. It links against the
"GDBRemoteCommunicationServer" and it uses this class to do most of the work.
Take a look at:
tools/lldb-platform/lldb-platform.cpp
This will show you how easy it will be to implement the GDB remote
communication for both the platform, and, in the future, for the
lldb-debugserver that will wrap up the "lldb_private::NativeDebug" layer for
remote debugging.
Greg Clayton
On Aug 25, 2012, at 6:34 AM, Carlo Kok <[email protected]> wrote:
> Hi,
>
> Can LLDB do remote debugging from another platform? (Linux -> OSX for
> example)? If so which side would load the symbols/have to have the source
> files?
>
> Is there documentation on how this protocol works?
>
>
> Thanks,
>
> Carlo Kok
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
