[lldb-dev] Can we remove this platform?

[David Earlam via lldb-dev]

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