[lldb-dev] Target and platform clarification request

[jingham at apple.com]

Just for completeness sake, the other thing that platforms encapsulate is are OS dependent features of the target system, for instance things like "How do I stop on new thread creation" or "What are the special trap handlers for the system?" and for other system specific features like "Queues" on Darwin...  

You can't really do this in the process because then you'd have to have ProcessGDBRemote know about all the systems it might connect to...  

Jim



> On Jul 3, 2014, at 10:22 AM, Greg Clayton <gclayton at apple.com> 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
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev