Hi Jonas, I agree you can remove Kalimba as a platform. We'll manage bringing it back upstream should we re-engage with llvm/lldb for Kalimba.
Some background: As CSR (Cambridge Silicon Radio plc) we experimented with using lldb for the Kalimba DSP. CSR plc was acquired by Qualcomm in August 2015 and became Qualcomm Technologies International, Ltd. o Kalimba Architecture 3 is a Harvard 24bit word-addressable deeply embedded DSP found in https://www.qualcomm.com/products/csr8675 used for Bluetooth aptX stereo headsets and speakers. o Kalimba Architecture 4 is a Harvard 32bit octet-addressable deeply embedded DSP and application processor first used for the multi-core CSRA6810x https://www.qualcomm.com/media/documents/files/csra68105-product-brief.pdf and now gaining wider adoption in https://www.qualcomm.com/products/qcc5100-series and https://www.qualcomm.com/products/qcc30xx-series based products which are typically used for Bluetooth aptX HD earbuds, headphones and speakers. o Kalimba Architecture 5 is a Harvard 24bit word-addressable deeply embedded audio DSP used in https://www.qualcomm.com/products/qualcomm-atlas-7 - an in-vehicle info and entertainment system-on-chip. The word-addressable feature of Architecture 3 and 5 Kalimba was nearly a total blocker for lldb adoption; an issue also faced by Embecosm for the 16bit AAP. http://lists.llvm.org/pipermail/llvm-dev/2017-February/109776.html Being deeply embedded, the cores provide some other unique system-level challenges for debug, development and test - including memory regions of different widths, power management, hardware breakpoint and memory patch units that made lldb not quite right for Kalimba. We also care deeply about optimised code debug fidelity (for example, our toolchain exploits DWARF's DW_LNS_negate_stmt). Such factors meant work was suspended on Kalimba as an lldb target around the time of the Qualcomm acquisition. (*) Providing infra-structure to run platform tests upstream is somewhat difficult. Development boards and custom debug probes can be expensive. Often we are creating the development tools for a new chip in advance of any silicon by using FPGAs or proprietary instruction set simulators that we cannot share. Nor can you usually easily repurpose end-consumer devices for tool testing because premium audio devices are also costly, run off a battery, and the code and const-data is fixed in none volatile memory or its debug port is not physically accessible or locked down since it contains an OEM's intellectual property. best regards, David Earlam Staff-Senior Engineer / Manager. Software Development Tools. Qualcomm Technologies International, Ltd. -----Original Message----- From: lldb-dev <lldb-dev-boun...@lists.llvm.org> On Behalf Of Pavel Labath via lldb-dev Sent: 27 March 2019 09:32 To: Jonas Devlieghere <jo...@devlieghere.com>; LLDB <lldb-dev@lists.llvm.org> Subject: [EXT] Re: [lldb-dev] Can we remove this platform? On 26/03/2019 23:16, Jonas Devlieghere via lldb-dev wrote: > Yesterday I stumbled upon the initialization code for the "Kalimba" > platform. It looks like this was added in 2014 and never had any tests. > If nobody is relying on this platform, I propose to remove it. > > Review: https://reviews.llvm.org/D59850 > > Thanks, > Jonas > Sounds good to me. I've had to touch this file a couple of times in the past due to interface changes, and I came close to proposing the same thing. [To be fair, none of the other platforms (except a single PlatformDarwin tests checking one very particular aspect of it) have specific tests either, though most of their code would be exercised if you run the test suite against a target supported by that particular platform. However, I doubt anyone if doing that for PlatformKalimba these days.] _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
