[lldb-dev] Target and platform clarification request

[Greg Clayton]

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

Great.

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

I am happy to stick with this as well, so lets say for now we will continue to treat core groups as processes, and processes with threads that represent each individual core.

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

Yes you will need to make a "Plugins/Platform/Kalimba" with a plug-in named "kalimba". It is possible to start getting ELF files loaded, but the big hurdle we will run into is you won't get any type introspection since the DWARF parser creates clang ASTs and converts DWARF back into DWARF ASTs. If your data layout is similar to another architecture, you could use that other architecture until you have your kalimba support in clang. As an example, there will be DWARF that describes a structure:

struct foo {
    int a;
    float b;
    uint64_t c;
};

We would create a clang AST and tell it to create a structure type "foo" and would add fields "a", "b", and "c" to that structure type and also assist the compiler with the layout by using data in the DWARF in case any #pragam or alignment attributes were used on any members. These clang AST types are used to display types with "frame variable" and also with expression results. Take a look at the ClangASTType.cpp file to get a feel for how we introspect types after they have been made into Clang types. So currently you would be able to make a target with your ELF file and get source correspondence, but you might fail to be able to display any variables.


Greg