You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We added sparse support to Zephyr and we are in the process of adding it to SOF, but without running automated sparse builds on PRs we are guaranteed to regularly break sparse-guarded features like cached vs. uncached memory disambiguation.
Describe the solution you'd like
A Zephyr+sparse build has to be executed for each PR along the lines of
west build -d tgl-sparse -b intel_adsp_cavs25 zephyr/samples/subsys/audio/sof -- -DSPARSE=y
Output has to be verified for regressions. It must be checked, that no sparse errors are added. Additionally we'll have to gradually verify and fix all currently reported sparse warnings.
Additional context
Note, that Xtensa support has only recently been added to upstream sparse, so we need to use the git version from https://git.kernel.org/pub/scm/devel/sparse/sparse.git/ instead of any distribution-provided packages.
Is using sparse from git + the west build command you gave enough to run sparse on Zephyr now? No other dependency, command or magic required?
Is the current sparse run mostly clean for Zephyr? If not, what is the order of magnitude of the number of errors left to fix?
You wrote "... and we are in the process of adding it to SOF" but your west build command already points at zephyr/sample/subsys/audio/sof which includes SOF code. Does "adding it to SOF" require a different command/process?
Before anything gets automated, it must be easy and well defined to run manually first.
Is using sparse from git + the west build command you gave enough to run sparse on Zephyr now? No other dependency, command or magic required?
@marc-hb I think so, yes, haven't tried to set up a new testing environment from scratch in a while though
Is the current sparse run mostly clean for Zephyr? If not, what is the order of magnitude of the number of errors left to fix?
At least when I added sparse to Zephyr I fixed all errors that popped up in an SOF build. And since Zephyr also uses other static code analysers their code looks mostly fine for those, yes.
You wrote "... and we are in the process of adding it to SOF" but your west build command already points at zephyr/sample/subsys/audio/sof which includes SOF code. Does "adding it to SOF" require a different command/process?
No, no different command or process. You can build SOF with Zephyr with sparse using that command now. By "in the process" I meant that we're adding uses of sparse constructs, namely of sparse address spaces. But even without those you can already build SOF with Zephyr with sparse.
Before anything gets automated, it must be easy and well defined to run manually first.
I'm not a sparse expert but I heard it can spot elusive caching issues that tend to require weeks-long task forces otherwise. At least that's how I understand the sales pitch :-)
@fredoh9 It was set to P1 per the weekly sync, as an important issue and one planned to be completed for this quarter (I believe, the other two requests are specifically mentioned as P2 Q4).
I thought people more familiar with this had already volunteered, but thanks for the quick explanation, I think I understand at a high level, but a variety of the smaller details are missing.
Is using sparse from git + the west build command you gave enough to run sparse on Zephyr now? No other dependency, command or magic required?
@marc-hb I think so, yes, haven't tried to set up a new testing environment from scratch in a while though
There is a golden, "from scratch", reference environment always available: the official zephyr-build container maintained by the Zephyr project and used by multiple CIs including SOF CI. I just tried running west build -d tgl-sparse -b intel_adsp_cavs25 zephyr/samples/subsys/audio/sof -- -DSPARSE=y in it and it failed in an unexpected way. west build -d tgl-sparse -b intel_adsp_cavs25 zephyr/samples/subsys/audio/sof works fine in the exact same environement (after deleting the stale tgl-sparse/ build directory). @lyakh can you please find what's wrong?
docker pull zephyrprojectrtos/zephyr-build
# in a different window while the above is running
west init zeptest
cd zeptest
git log --oneline
d1d5acd2cd (HEAD -> main, origin/main, origin/HEAD) coding guidelines: comply with MISRA C:2012 Rule 8.2
05ec016157 MAINTAINERS: Add keith-packard as C library collaborator
d326683b56 MAINTAINERS: Add picolibc entry
west update sof hal_extensa
cd ..
docker run -u 1000 -ti -v "$(pwd)":/workdir docker.io/zephyrprojectrtos/zephyr-build:latest /bin/bash
chown -R 1000 zeptest
cd zeptest
export ZEPHYR_BASE=/workdir/zeptest/zephyr
# just works, obviously because it's routinely tested in CI
west build -d tgl-sparse -b intel_adsp_cavs25 zephyr/samples/subsys/audio/sof
# fails
rm -rf tgl-sparse
west build -d tgl-sparse -b intel_adsp_cavs25 zephyr/samples/subsys/audio/sof -- -DSPARSE=y
-- Generated device_extern.h: /workdir/zeptest/tgl-sparse/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: /workdir/zeptest/tgl-sparse/zephyr/dts.cmake
Parsing /workdir/zeptest/zephyr/Kconfig
Loaded configuration '/workdir/zeptest/zephyr/boards/xtensa/intel_adsp_cavs25/intel_adsp_cavs25_defconfig'
Merged configuration '/workdir/zeptest/zephyr/samples/subsys/audio/sof/prj.conf'
Merged configuration '/workdir/zeptest/zephyr/samples/subsys/audio/sof/boards/intel_adsp_cavs25.conf'
Configuration saved to '/workdir/zeptest/tgl-sparse/zephyr/.config'
Kconfig header saved to '/workdir/zeptest/tgl-sparse/zephyr/include/generated/autoconf.h'
warning: DAI_SSP_HAS_POWER_CONTROL (defined at drivers/dai/intel/ssp/Kconfig.ssp:16) was assigned
the value 'y' but got the value 'n'. Check these unsatisfied dependencies: DAI_INTEL_SSP (=n), DAI
(=n). See http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_DAI_SSP_HAS_POWER_CONTROL and/or
look up DAI_SSP_HAS_POWER_CONTROL in the menuconfig/guiconfig interface. The Application Development
Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual
might be helpful too.
CMake Error at /workdir/zeptest/zephyr/cmake/compiler/gcc/target.cmake:17 (message):
C compiler
/opt/toolchains/zephyr-sdk-0.14.2/xtensa-intel_s1000_zephyr-elf/bin/xtensa-intel_s1000_zephyr-elf-gcc
not found - Please check your toolchain installation
Call Stack (most recent call first):
/workdir/zeptest/zephyr/cmake/modules/target_toolchain.cmake:63 (include)
/workdir/zeptest/zephyr/cmake/modules/zephyr_default.cmake:121 (include)
/workdir/zeptest/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
/workdir/zeptest/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:91 (include_boilerplate)
CMakeLists.txt:5 (find_package)
-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: /usr/local/bin/cmake -DWEST_PYTHON=/usr/bin/python3 -B/workdir/zeptest/tgl-sparse -S/workdir/zeptest/zephyr/samples/subsys/audio/sof -GNinja -DBOARD=intel_adsp_cavs25 -DSPARSE=y
/opt/toolchains/zephyr-sdk-0.14.2/xtensa-intel_s1000_zephyr-elf/bin/xtensa-intel_s1000_zephyr-elf-gcc does exist in the container.
Wow, this error message is one of the most irrelevant-looking I've ever seen. Could you file a new Zephyr bug about it? The Zephyr project has incredibly good CMake experts; we can ask them for ideas on how to fix this error message.
After a manual apt install sparse in the container the build now fails like this below, it looks like it's not using an appropriate toolchain?
Before adding sparse to CI it needs to be reasonably easy to use outside CI. Failures in CI needs to be reproducible outside CI, otherwise CI is just wasting energy producing reports that can't be acted upon.
@lyakh
I guess you use the default Zephyr SDK gcc xtensa-intel_s1000_zephyr-elf-gcc to build zephyr with Sparse. The default gcc also works for me without errors. The above errors are generated by xcc.
@lyakh I guess you use the default Zephyr SDK gcc xtensa-intel_s1000_zephyr-elf-gcc to build zephyr with Sparse. The default gcc also works for me without errors. The above errors are generated by xcc.
@keqiaozhang yes, this is compiler-sensitive and since it's a Zephyr feature I think the main target would be the Zephyr toolchain. And I don't think we need to use xcc for this. We use this to get sparse output - warnings and errors, we don't actually care about compilation results.
@lyakh Thanks for explanation.
I will add a GitHub action to check the sparse build in CI next.
One tip, we need to set the REAL_CC to Zephyr SDK toolchain, this will let the cgcc use Zephyr SDK toolchain as the compiler to invoke. export REAL_CC=/$YOUR_PATH/zephyr-sdk-0.14.2/xtensa-intel_s1000_zephyr-elf/bin/xtensa-intel_s1000_zephyr-elf-gcc
Activity
marc-hb commentedon Jun 15, 2022
Thanks @lyakh for filing this! Some questions:
west buildcommand already points atzephyr/sample/subsys/audio/sofwhich includes SOF code. Does "adding it to SOF" require a different command/process?Before anything gets automated, it must be easy and well defined to run manually first.
lyakh commentedon Jun 20, 2022
@marc-hb I think so, yes, haven't tried to set up a new testing environment from scratch in a while though
At least when I added sparse to Zephyr I fixed all errors that popped up in an SOF build. And since Zephyr also uses other static code analysers their code looks mostly fine for those, yes.
No, no different command or process. You can build SOF with Zephyr with sparse using that command now. By "in the process" I meant that we're adding uses of sparse constructs, namely of sparse address spaces. But even without those you can already build SOF with Zephyr with sparse.
fredoh9 commentedon Jun 22, 2022
Enhancement and P1 is not usual case. If this is P1, we need a assignee. @greg-intel will you take this?
marc-hb commentedon Jun 22, 2022
I'm not a sparse expert but I heard it can spot elusive caching issues that tend to require weeks-long task forces otherwise. At least that's how I understand the sales pitch :-)
greg-intel commentedon Jun 22, 2022
@fredoh9 It was set to P1 per the weekly sync, as an important issue and one planned to be completed for this quarter (I believe, the other two requests are specifically mentioned as P2 Q4).
I thought people more familiar with this had already volunteered, but thanks for the quick explanation, I think I understand at a high level, but a variety of the smaller details are missing.
marc-hb commentedon Jun 22, 2022
There is a golden, "from scratch", reference environment always available: the official
zephyr-buildcontainer maintained by the Zephyr project and used by multiple CIs including SOF CI. I just tried runningwest build -d tgl-sparse -b intel_adsp_cavs25 zephyr/samples/subsys/audio/sof -- -DSPARSE=yin it and it failed in an unexpected way.west build -d tgl-sparse -b intel_adsp_cavs25 zephyr/samples/subsys/audio/sofworks fine in the exact same environement (after deleting the staletgl-sparse/build directory). @lyakh can you please find what's wrong?/opt/toolchains/zephyr-sdk-0.14.2/xtensa-intel_s1000_zephyr-elf/bin/xtensa-intel_s1000_zephyr-elf-gccdoes exist in the container.lyakh commentedon Jun 23, 2022
@marc-hb right, the error message comes out misleading.
sparseisn't installed. As explained, you have to install it manually in your docker image from git. For an explanation (and eventual fox for the error message) see this snippethttps://github.com/zephyrproject-rtos/zephyr/blob/ee22ae79a4aaa2efb90580888737257724cb5e7d/cmake/compiler/gcc/target.cmake#L8-L18
marc-hb commentedon Jun 23, 2022
Wow, this error message is one of the most irrelevant-looking I've ever seen. Could you file a new Zephyr bug about it? The Zephyr project has incredibly good CMake experts; we can ask them for ideas on how to fix this error message.
Also, can you please addIt's a one-line change.sparseto this list?https://github.com/zephyrproject-rtos/docker-image/blob/master/Dockerfile
After a manual
apt install sparsein the container the build now fails like this below, it looks like it's not using an appropriate toolchain?Before adding sparse to CI it needs to be reasonably easy to use outside CI. Failures in CI needs to be reproducible outside CI, otherwise CI is just wasting energy producing reports that can't be acted upon.
nklayman commentedon Jun 23, 2022
@marc-hb I think you need to build sparse from source in order for it to support the xtensa architecture, as per @lyakh's earlier comment:
That would explain why you got an error about using the wrong toolchain.
marc-hb commentedon Jun 23, 2022
Thanks @nklayman , good catch.
@lyakh, from the top of your head could you share a quick and barely tested set of commands that would build sparse inside the container?
lyakh commentedon Jun 24, 2022
@marc-hb
keqiaozhang commentedon Jun 24, 2022
@lyakh I have installed the sparse, but run to below errors:
I updated the llvm and west to latest, but didn't help. Any ideas?
keqiaozhang commentedon Jun 27, 2022
@lyakh
I guess you use the default Zephyr SDK gcc
xtensa-intel_s1000_zephyr-elf-gccto build zephyr with Sparse. The default gcc also works for me without errors. The above errors are generated byxcc.lyakh commentedon Jun 27, 2022
@keqiaozhang yes, this is compiler-sensitive and since it's a Zephyr feature I think the main target would be the Zephyr toolchain. And I don't think we need to use xcc for this. We use this to get sparse output - warnings and errors, we don't actually care about compilation results.
keqiaozhang commentedon Jun 27, 2022
@lyakh Thanks for explanation.
I will add a GitHub action to check the sparse build in CI next.
One tip, we need to set the
REAL_CCto Zephyr SDK toolchain, this will let the cgcc use Zephyr SDK toolchain as the compiler to invoke.export REAL_CC=/$YOUR_PATH/zephyr-sdk-0.14.2/xtensa-intel_s1000_zephyr-elf/bin/xtensa-intel_s1000_zephyr-elf-gccmarc-hb commentedon Sep 21, 2022
EDIT: first attempt was
Final PR submitted in
EDIT: not final after all, see new requirements scattered in
.github: fail on errors and address space warnings in sparse output