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
Re: [lldb-dev] Can we remove this platform?
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 On Behalf Of Pavel Labath via lldb-dev Sent: 27 March 2019 09:32 To: Jonas Devlieghere ; LLDB 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
Re: [lldb-dev] Test suite failures on Fedora Linux?
On 26/03/2019 14:48, David Zarzycki via lldb-dev wrote: On Mar 26, 2019, at 3:07 AM, Jan Kratochvil wrote: On Mon, 25 Mar 2019 19:47:36 +0100, David Zarzycki via lldb-dev wrote: Also, given that two of the test failures are Intel specific (the mxcsr register write failures), what class of hardware do you use? My workstation is Skylake-SP based, if it matters. OK, I agree it PASSes for me on Haswell-EP (E5-2630v3) but it also FAILs for me on Kaby Lake Refresh (i7-8650U). Also kernel-5.0.3-200.fc29.x86_64. It looks like this is a known issue: https://bugs.llvm.org/show_bug.cgi?id=39958 Ok, so I've managed to get a hold of a machine which reproduces this problem. It's a debian based system running linux 4.19, which should confirm that this is a hardware issue. I'll try to find some time to diagnose this later this week. My guess is that we're just setting some mxcsr value that these CPUs don't like, and we need to be more conservative in what we write in the tests. Any ETA on renaming the variables? The bug you mentioned also had > someone offer to rename the variables in late 2017, but that seemingly > never happened. I believe the rename that bug is referring to really did happen. What you are seeing is a new test, which also uses "a" as a meaningless identifier. I'll do the rename right away. pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Test suite failures on Fedora Linux?
Sorry, was traveling and the internet wasn't good enough for git. Thanks for pushing a fix Pavel! - Raphael Am Mi., 27. März 2019 um 16:37 Uhr schrieb Pavel Labath via lldb-dev : > > On 26/03/2019 14:48, David Zarzycki via lldb-dev wrote: > > > >> On Mar 26, 2019, at 3:07 AM, Jan Kratochvil > >> wrote: > >> > >> On Mon, 25 Mar 2019 19:47:36 +0100, David Zarzycki via lldb-dev > >> wrote: > >>> Also, given that two of the test failures are Intel specific (the > >>> mxcsr register write failures), what class of hardware do you > >>> use? My workstation is Skylake-SP based, if it matters. > >> > >> OK, I agree it PASSes for me on Haswell-EP (E5-2630v3) but it also > >> FAILs for me on Kaby Lake Refresh (i7-8650U). Also > >> kernel-5.0.3-200.fc29.x86_64. > > > > It looks like this is a known issue: > > > > https://bugs.llvm.org/show_bug.cgi?id=39958 > > > > Ok, so I've managed to get a hold of a machine which reproduces this > problem. It's a debian based system running linux 4.19, which should > confirm that this is a hardware issue. > > I'll try to find some time to diagnose this later this week. My guess is > that we're just setting some mxcsr value that these CPUs don't like, and > we need to be more conservative in what we write in the tests. > > > > Any ETA on renaming the variables? The bug you mentioned also had > > someone offer to rename the variables in late 2017, but that seemingly > > never happened. > > I believe the rename that bug is referring to really did happen. What > you are seeing is a new test, which also uses "a" as a meaningless > identifier. > > I'll do the rename right away. > > pl > ___ > 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
Re: [lldb-dev] Can we remove this platform?
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 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 On Behalf Of Pavel > Labath via lldb-dev > Sent: 27 March 2019 09:32 > To: Jonas Devlieghere ; 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
[lldb-dev] Release 7.1.0 -rc1 has been tagged
Hi, I've just tagged 7.1.0-rc1. Testers, please begin testing and reporting results. Thanks, Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] What is the correct behavior of SBModule::GetVersion with a version number of 0.0.0
If you have a library that has a version number of 0.0.0,
uint32_t SBModule::GetVersion(uint32_t *versions, uint32_t num_versions)
will return a result of 2 (which is the number of elements it put into
num_versions) and the two elements it actually stuffed into the versions array
will be {UINT32_MAX, 0}.
That seems like a weird result to me, but the code goes to some trouble to make
this up. I was wondering what the reason for this is?
This came to my attention because the swig wrapper for GetVersion treats
UINT32_MAX as the sign that it should stop filling elements in the list array
(even if the element that is UINT32_MAX is earlier in the returned array than
the result that GetVersion returns.) That is, we do:
uint32_t count = result;
if (count >= arg3)
count = arg3;
PyObject* list = PyList_New(count);
for (uint32_t j = 0; j < count; j++)
{
if (arg2[j] < UINT32_MAX)
{
PyObject* item = PyInt_FromLong(arg2[j]);
int ok = PyList_SetItem(list,j,item);
if (ok != 0)
{
resultobj = Py_None;
break;
}
}
else
break;
}
And so if the 0th element in the list in UINT32_MAX, we make a Python list that
we say we are going to fill with two elements, but don't put anything in it,
and so if you try to iterate over this list Python crashes.
The wrapper behavior seems clearly wrong. If you say you are making an array
with N elements, you need to put N elements in it or iterating over it will
crash. That's easy to fix.
But then if we have a library whose actual version (e.g. as printed by the llvm
objdump) is 0.0.0, we will call it {4294967295, 0} which just seems weird.
So I was wondering whether the code in GetVersion that fills the Major version
with UINT32_MAX was done for some reason, or is just an accident I should fix.
BTW, this comes about because llvm::VersionTuple doesn't have a HasMajor flag,
and the only way to test the validity of the major version is to call
"VersionTuple::empty" and that ONLY checks the values of the version numbers.
So something that has HasMinor = true but all the version numbers are 0 will
say it is empty - which also seems a little odd to me...
Jim
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
