[lldb-dev] Target and platform clarification request

[Matthew Gardiner]

Greg Clayton wrote:
>> 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.
Yes, sure. We at CSR are in the process of getting someone aboard to 
work on an LLVM backend for our Kalimbas. We are slowly changing bits of 
our existing toolchain (e.g. with an official EM_MACHINE number + an ELF 
notes section) to see how far we can get (before the LLVM backend) with 
an lldb port.

> 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)
As I mentioned offline to you and Todd, we have proprietary USB/SPI 
connections to our chips. So one host PC may be connected to several 
boards (each with a CSR chip) with one USB connection per board. 
Furthermore each chip may have several cores which may or may not share 
architectures (Kalimba, ARM, 8051-clone etc.). And yes I think we need 
to (currently) map a core to a process.

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

Yes, that looks like a nice plan. I see the lldb "target instance" is 
implicitly created. For the embedded world I'm curious as to how now to 
associate each of these targets with potentially different ELF files.
>
> 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

Cool. So let me see if I've understood this correctly. Currently we have 
the "platform process" concept, so that means for embedded stuff without 
OS support we emulate running cores with processes. However, in the 
future, if we add a "platform bareboard" concept which allows attachment 
to cores without OSes? Personally, I'm content to remain with "platform 
process" concept for cores, since we rely on the underlying lldb Process 
C++ implementation to debug (read memory/registers etc.)  to debug these 
entities. I may have the wrong end of the stick here, though.
>
> Again, we can make the platform all we need it to be so we can make LLDB a great embedded debugger.
I hope so. I'm trying to understand how to do this without busting the 
existing architecture. But I guess it's possible with incremental steps.
>> 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.
Well, all I'm trying to achieve right now is arrange that when I load a 
Kalimba ELF (with suitable EM_MACHINE and possibly a matching .notes 
section) we get a suitable target entry:

e.g.
target #0: kal.elf ( arch=kalimba-csr-unknown, platform=kalimba )

 From earlier in this thread I'm given to understand that to do this 
right I need to create Plugins/Platform/Kalimba (i.e. "Platform 
Kalimba"). And from my own work I think I need the matching definitions 
in llvm::Triple to make this fly. Since we don't have a clang/llvm 
person on board yet, I was hoping I could at least get my  "Platform 
Kalimba" working without full clang support. Please tell me if you don't 
think this is possible with ELF/DWARF built by other toolchains. I 
appreciate that expression evaluation would not work, but did think that 
things like stack unwind, source-line step and other debug primitives 
would still work.
> Let me know if you have any more questions.
>
> Greg

Will do. Thanks again.
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.