Greg Clayton wrote:
Greg Clayton 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.