[lldb-dev] Can we remove this platform?

Jonas Devlieghere via lldb-dev lldb-dev at lists.llvm.org
Wed Mar 27 09:22:44 PDT 2019


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 <dearlam at 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-bounces at lists.llvm.org> On Behalf Of Pavel
> Labath via lldb-dev
> Sent: 27 March 2019 09:32
> To: Jonas Devlieghere <jonas at devlieghere.com>; LLDB <
> lldb-dev at 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 at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190327/5b351554/attachment-0001.html>


More information about the lldb-dev mailing list