[lldb-dev] Target and platform clarification request

[Matthew Gardiner]

Greg Clayton wrote:
>> 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.
Right, thanks. Am I correct to assume that I'll need to add kalimba 
(architecture) and CSR (vendor) to llvm::Triple to really get this plan 
to take-off?

And would this implementation of the PlatformKalimba reside solely 
within lldb? I'm asking since I see that we have a command tool called 
lldb-platform. (Does this fit into to my world of custom platforms for 
embedded targets?).

>>
>> 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
Thanks for this. I guess some of these actions can't really be mapped 
into CSRs current embedded scenarios, since they have no OS or 
filesystem. (Basically the instruction code is copied into the chip's 
ROM/RAM/FLASH/whatever, and when the device is reset, the processor 
understands which device/address to start to fetch from).

However some of these actions are applicable, and indeed useful. Our 
current debugger has a poor way of mapping different ELFs to a 
particular context - we only really support having just one (or zero) 
ELFs for any particular running core - so option 4. may be of benefit. 
5. and 6. are also relevant, although we don't have the real processes, 
the concept of Process 1 in an 
unattached/attached-running/attached-stopped state would be useful.

>
> 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.
Yep, understood. Presumably to support this effort I'll need to augment 
the ArchType and VendorType enumerations of llvm::Triple and the 
relevant parseXXX:: and getXXXName:: functions, as I referred to above.

> 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.

Oh, I see, we have a notion of the local and remote platforms when 
working with embedded debug.

thanks for this help, Greg, it is somewhat clearer now.

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.