[lldb-dev] Target and platform clarification request

[Greg Clayton]

> On Jul 1, 2014, at 6:04 AM, Matthew Gardiner <mg11 at csr.com> wrote:
> 
> Hi all,
> 
> I have modified my local copy of lldb in order that it can gdb-remote to an in-house gdb-rsp server. However after I connect to my target, the target list command informs me that my target's platform is "host".
> 
> e.g.
> 
> (lldb) target list
> Current targets:
> * target #0: /home/mg11/src/main/devtools/main/heracles/csrgdbserver/test/examples/simple/kalgsd5te_hello.elf ( arch=kalimba-csr-unknown, platform=host, pid=1, state=stopped )
> 
> Is this correct for a embedded target connected over gdb-rsp?

No, you really should add a new platform that claims "kalimba-csr-unknown" as its architecture.
> 
> 
> When I invoke platform list I see:
> 
> (lldb) platform list
> Available platforms:
> host: Local Linux user platform plug-in.
> remote-freebsd: Remote FreeBSD user platform plug-in.
> remote-linux: Remote Linux user platform plug-in.
> remote-windows: Remote Windows user platform plug-in.
> remote-gdb-server: A platform that uses the GDB remote protocol as the communication transport.
> 
> So I wondered why my target doesn't report remote-gdb-server as it's target. Should it?

No, not unless you implement a lldb-platform style platform for "kalimba-csr-unknown". The current lldb-platform speaks the GDB remote protocol, but adds new packets.
> 
> 
> Could someone clarify what this concept of platform means? I understand the concept of the host as being the Machine/OS where the debugger user is worked at, and the target as being the "thing being debugged", which could be co-located on the host (in either a 32-bit or 64-bit form) or remotely located, in particular for an embedded device, but where does the idea of the platform fit in?

Platforms do the following:
1 - Resolve executables (you might say "target create ls" and your platform could say "oh, 'ls' is in /usr/local/kalimba/root/bin/ls)
2 - Give a list of supported architectures ("kalimba-csr-unknown" for your platform)
3 - Find local copies of a binary when remote debugging and the dynamic loader gives a list of shared libraries your binary is linking against (for iOS, the "remote-ios" can resolve "/usr/lib/dyld" to be "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/lib/dyld")
4 - Find debug symbols for your binaries (they might be cached in your development kit folder)
5 - List processes that can be attached to (try "platform process list" after launching LLDB)
6 - Attach to a process from #5
7 - Launch a new process
8 - upload/download files
9 - install executables

So many of these things (1 - 4) can be done without being connected to the remote platform (the lldb_private::Platform subclass for your architecture can do these things locally on the current machine without being connected to the remote platform. But many (5 - 9) require being attached.

If you write a platform that recognizes "kalimba-csr-unknown", you can say:

(lldb) file /path/to/kalimba/a.out

And it will query all installed platforms and see if any claim the current architecture. If you made "PlatformKalimba", your platform be matched up with the binary since #2 from above in your platform would return "kalimba-csr-unknown", and your platform would automatically be selected.

The way the "remote-gdb-server" is currently used it by other platforms (like PlatformPOSIX) have a shared pointer to a platform as a member variable:

    lldb::PlatformSP m_remote_platform_sp; // Allow multiple ways to connect to a remote POSIX-compliant OS

And this platform can implement items 5-9, while the local subclass "PlatformKalimba" can take care of doing the specific local file system kinds of things (locating all development kits for Kalimba on the current host, finding all things you have debug symbols for, resolve executables, etc). When you then connect to your platform:

(lldb) platform connect <url>

Then your "PlatformKalimba" would then create a connection to a remote lldb-platform (which is a GDB remote protocol based platform) if you ever require the ability to do the steps 5-9 above. Otherwise, the platform is still useful for locating local copies of your executables.

Let me know if you have anymore questions.

Greg