wip: build: add support for llvm clang#10759
Draft
lgirdwood wants to merge 9 commits into
Draft
Conversation
Add --llvm-clang LLVM_BUILD_DIR flag to xtensa-build-zephyr.py for
building SOF with a custom LLVM/Clang toolchain instead of xt-clang
or Zephyr SDK GCC.
When specified, the script:
- Auto-generates a platform-specific clang wrapper script that:
- Filters GCC-only flags (-fno-reorder-functions, -fno-defer-pop,
--param=*, -fstrict-overflow)
- Translates -mlongcalls to -mlong-calls
- Adds --target for the Xtensa SoC triple
- Adds -fno-integrated-as (GCC external assembler)
- Adds -B paths for GCC assembler/linker from Zephyr SDK
- Adds -I path for SoC-specific core-isa.h
- Forces ZEPHYR_TOOLCHAIN_VARIANT=zephyr for GCC assembler/linker
- Overrides CMAKE_C_COMPILER and CMAKE_ASM_COMPILER
Usage:
scripts/xtensa-build-zephyr.py --llvm-clang ~/llvm-project/build ptl
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Switch from ZEPHYR_TOOLCHAIN_VARIANT=zephyr with wrapper script overrides to ZEPHYR_TOOLCHAIN_VARIANT=llvm which has native Xtensa Clang support. The llvm variant (cmake/toolchain/llvm/target.cmake) handles: - Compiler detection via LLVM_TOOLCHAIN_PATH - GCC assembler/linker integration via CROSS_COMPILE - Correct -B paths for assembler and linker discovery - LLEXT shared library link wrapper This eliminates the need for the wrapper script and symlink dance that was required with the zephyr variant to override find_program(). Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com>
- llext_link_helper.py: Treat .rodata as readonly even when marked writable by the Clang/objcopy LLEXT pipeline, and place readonly sections BEFORE .text so Xtensa l32r instructions (which can only reach backwards up to 256KB) can access .rodata literals. - zephyr/CMakeLists.txt: Make -mtext-section-literals conditional via check_c_compiler_flag (Clang doesn't support it), and force the Zephyr SDK GCC linker for the LLEXT shared library link step. Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com>
Disable the Intel UAOL DAI driver/usage when building with Clang to work around build failures. UAOL is gated off in the board Kconfig default and the corresponding DAI dispatch arms are stubbed out with '#if 0' until a proper Clang-compatible fix lands. Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com>
The LOG_CORE_ID_PREFIX default produces logging output paths that trigger Clang build issues. Disable the board-level default until a proper fix is in place. Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com>
Add intel_adsp_ace30_ptl_llvm_qemu.conf overlay config for single-core LLVM QEMU testing. Applied on top of the base intel_adsp_ace30_ptl.conf via -DEXTRA_CONF_FILE=. Key overrides: - CONFIG_CORE_COUNT=1, CONFIG_SMP=n: avoids SMP sync hang in QEMU - CONFIG_LLEXT=n: missing TIE headers (xt_FP.h) in LLVM - CONFIG_FORMAT_CONVERT_HIFI3=n: same TIE dependency - CONFIG_USERSPACE=n, CONFIG_PM=n: reduces single-core init complexity - CONFIG_LOG_MODE_DEFERRED=y: avoids z_cbvprintf_impl crash path Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com>
lgirdwood
changed the title
tmleman
reviewed
May 13, 2026
Contributor
There was a problem hiding this comment.
This script was far too long from the beginning. I wonder if it would be possible to move some of the things it's doing directly to west. Perfect solution would be setting some environments and calling west in workflow.
Soon it will be a wrapper on west having over 2K lines of code. My local script has 250 with comments :)
Member
Author
There was a problem hiding this comment.
the script has a lot of convenience - 2k lines is not a problem, especially today.
|
@lgirdwood I take your patches and can build LLVM. I also build SOF with it and it looks OK. I run in qemu and see lots of code being run to idle. I think this looks OK but not expert on SOF. I am working on some LLVM updates for fun that I will send. Thank you. |
|
@lgirdwood I made 2 PRs last night for HIFI and FLIX , please check lgirdwood/llvm-project#1 |
Member
Author
@hliao8 PRs look OK, let me try on my devices and qemu and get back to you. |
Zephyr's FindZephyr-sdk.cmake intentionally skips auto-discovery when ZEPHYR_TOOLCHAIN_VARIANT=llvm, expecting the user to point ZEPHYR_SDK_INSTALL_DIR at the SDK that provides the GNU Xtensa binutils / sysroot the LLVM clang driver wraps around. When neither the user nor the environment supplies that variable the build fails late with confusing 'string.h: file not found' / malformed -isystem errors. Auto-detect a zephyr-sdk-* directory under $HOME, /opt, or /usr/local (highest version wins) and export ZEPHYR_SDK_INSTALL_DIR before invoking west when the user passes --llvm-clang. This keeps the LLVM build flow as one command for the common case while still respecting any value the user has already exported. Signed-off-by: Henry Liao <hliao8@proton.me>
The HiFi3 / HiFi4 / HiFi5 sources unconditionally include <xtensa/config/defs.h>, a header that ships only with the Cadence xt-clang / xt-gcc toolchains. The LLVM clang toolchain variant uses the Zephyr SDK GNU Xtensa binutils for assembly/linking but does not expose that Cadence-internal header, so every HiFi translation unit fails to find it even though the body of the file is guarded by SOF_USE_HIFI(...) and is unreachable for the LLVM build. Wrap the include in __has_include so the compiler silently skips it on toolchains that lack the header. The HiFi intrinsics are already supplied by <xtensa/tie/xt_hifiN.h>, which the LLVM toolchain does provide. No functional change for the Cadence toolchain path. Signed-off-by: Henry Liao <hliao8@proton.me>
Member
Author
Ok, merged, can build and boot FW, load topologies but something wrong at trigger(). Its definitely in the right direction. I'll take a look at trigger when time permits. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Just a heads up for anyone interested in llvm clang support to build SOF xtensa targets. Its still very early WIP with lots of work still to do but end result should be a single xtensa clang compiler for all SOF targets for CI, twister etc. Opens door to other non C based languages long term.
Needs zephyrproject-rtos/zephyr#108765
and
llvm/llvm-project@main...lgirdwood:llvm-project:upstream/dev