Thanks for the background, David! I've removed the platform in r357086.
Cheers, Jonas On Wed, Mar 27, 2019 at 5:42 AM David Earlam <dear...@qti.qualcomm.com> wrote: > 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
