[lldb-dev] Target and platform clarification request

[Greg Clayton]

> On Jul 2, 2014, at 6:11 AM, Matthew Gardiner <mg11 at csr.com> wrote:
> 
> 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?

If you want expression parsing and for us to be able to make types using Clang ASTs it is going to require that you hook up your architecture within LLVM and Clang. Otherwise we won't be able to make a clang target so that we can covert the DWARF debug info into Clang ASTs.

> And would this implementation of the PlatformKalimba reside solely within lldb?

Yes it would be in the core of lldb.

> I'm asking since I see that we have a command tool called lldb-platform.

This tool links against the core of lldb, not the public API, but the core, so the PlatformKalimba would be available in lldb-platform as well.

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

We can also modify the lldb_private::Platform to state it is a bare board somehow and add bareboard functionality to the platforms. Let us know what you would want from a bare board Platform and we can get this included. Often times with JTAG style debugging, the software that talks to the JTAG can often enumerate the core groups you can attach to and each core can be a separate architecture. In these scenarios the following mappings would hold true:
- different core groups would map to the equivalent of processes
- a group of cores would be represented by lldb_private::Process which a lldb_private::Thread representing a single core in the group (all cores must have same architecture)

Then you could attach to your platform and currently do:

(lldb) platform process list
PID    PARENT USER       ARCH                  NAME
====== ====== ========== ===================== ============================
1                        armv7-unknown-unknown ARMV7 (2 cores)
2                        armv5-unknown-unknown ARMV5 (1 core)

Then you could do:

(lldb) platform process attach --pid 1
(lldb) platform process attach --pid 2

We would add functionality to the platform like:

(lldb) platform bareboard list
Core   ARCH                  Description
====== ===================== ============================
1      armv7-unknown-unknown ARMV7 (2 cores)
2      armv5-unknown-unknown ARMV5 (1 core)
(lldb) platform bareboard attach 1

Again, we can make the platform all we need it to be so we can make LLDB a great embedded debugger.

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

again, see the above mapping of "processes" to "core groups" and see if that makes more sense.

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

Yes, full clang support is actually required so we can make a clang Target and clang AST so we can represent your types and do expression evaluation. I was assuming this was already done, but this is a large amount of work if it isn't. Unless you can use another architecture that clang already supports, but that would be a large hack.

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

Let me know if you have any more questions.

Greg