[ATFE] Add build controls for layered runtime payloads by simpal01 · Pull Request #877 · arm/arm-toolchain

simpal01 · 2026-06-09T15:14:17Z

Add CMake cache options to control which runtime payloads are built and installed for layered variants. This allows llvm-libc variants to install only the required minor-variant payload, while also making compiler-rt, llvm-libc core archives, and llvm-libc support libraries independently selectable.

These options are currently defined in CMake so the layering flow can be enabled, but they are expected to move into the variant JSON handling in a follow-up patch..

vhscampos · 2026-06-25T10:06:22Z

 set(ENABLE_LIBCXX_TESTS ${ENABLE_LIBCXX_TESTS_def} CACHE BOOL "Enable libcxx tests.")
+set(ENABLE_LLVMLIBC_MINOR_VARIANT ${ENABLE_LLVMLIBC_MINOR_VARIANT_def} CACHE BOOL "Install only the llvm-libc minor variant payload for this variant.")
+set(LLVMLIBC_SUBARCHIVE_NAME ${LLVMLIBC_SUBARCHIVE_NAME_def} CACHE STRING "llvm-libc subarchive to install when ENABLE_LLVMLIBC_MINOR_VARIANT is enabled.")
+set(ENABLE_LLVMLIBC_CORE_LIBS ${ENABLE_LLVMLIBC_CORE_LIBS_def} CACHE BOOL "Build and install the core llvm-libc library archives.")


What are the "core llvmlibc" libraries?

Here, “core llvm-libc libraries” means the libraries produced by the upstream libc runtime build itself, mainly the target specific llvm-libc archives installed.

That is separate from llvmlibc-support, which is ATfE’s support layer under arm-software/embedded/llvmlibc-support. The support layer builds things like libcrt0.a, libcrt0-none.a, libcrt0-semihost.a, and libsemihost.a.

I will change the help text to avoid the vague word “core”.

set(ENABLE_LLVMLIBC_CORE_LIBS ${ENABLE_LLVMLIBC_CORE_LIBS_def} CACHE BOOL "Build and install library archives from the llvm-libc build.")

vhscampos · 2026-06-25T10:06:58Z

 set_property(CACHE LIBRARY_BUILD_TYPE PROPERTY STRINGS ${SUPPORTED_LIBRARY_BUILD_TYPES})

 set(ENABLE_CXX_LIBS ${ENABLE_CXX_LIBS_def} CACHE BOOL "Build CXX libs")
+set(ENABLE_COMPILER_RT_LIBS ${ENABLE_COMPILER_RT_LIBS_def} CACHE BOOL "Build compiler-rt libraries.")


The descriptions below mention "build and install", where this one is limited to "build". Does this make sense?

I think ENABLE_COMPILER_RT_LIBS also enables the install step for
compiler-rt, so I agree the description should say “Build and install” for consistency.

vhscampos · 2026-06-25T10:10:36Z

+# the files that differ from the base layer.
+if(ENABLE_LLVMLIBC_MINOR_VARIANT)
+    if(NOT C_LIBRARY STREQUAL llvmlibc)
+        message(FATAL_ERROR "ENABLE_LLVMLIBC_MINOR_VARIANT is only supported with C_LIBRARY=llvmlibc.")


Isn't the CMake var to enable llvm libc LLVM_TOOLCHAIN_ENABLE_LLVMLIBC?

LLVM_TOOLCHAIN_ENABLE_LLVMLIBC is the top-level option for enabling the llvm-libc runtime. This check is in the arm-runtimes subproject, where the selected libc is passed in as C_LIBRARY . arm-multilib configures it with -DC_LIBRARY=${C_LIBRARY} So C_LIBRARY=llvmlibc is the local condition we need here.

But since this CMakeLists.txt here is internal, I wonder if the error message should mention the public facing CMake variable instead. I am not sure, just bringing this up for reflection

vhscampos · 2026-06-25T10:12:27Z

+    add_custom_target(compiler_rt-configure)
+    add_custom_target(compiler_rt-build)
+    add_custom_target(compiler_rt-install)


What's the point of these custom targets?

Those empty add_custom_target() calls are placeholders for when ENABLE_COMPILER_RT_LIBS=OFF.

When compiler-rt is disabled, those targets would not exist. But the rest of the build graph still refers to them, for example:

picolibc has DEPENDS compiler_rt-install

cxxlibs has DEPENDS compiler_rt-install

etc

So the empty targets keep those dependencies valid and make them no-ops when compiler-rt is disabled rather than forcing every dependency site to special-case compiler-rt.

I think it would make more sense to only set the dependencies when they're actually needed, rather than have placeholder targets that are never intended to build anything.

I agree with @dcandler

vhscampos · 2026-06-25T10:13:04Z

+    add_custom_target(compiler_rt_profile-configure)
+    add_custom_target(compiler_rt_profile-build)
+    add_custom_target(compiler_rt_profile-install)


These are also the same placeholder pattern

vhscampos · 2026-06-25T10:13:41Z

        # Let CMake know we're cross-compiling
        -DCMAKE_SYSTEM_NAME=Generic
        -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY
+        -DLLVM_LIBC_ENABLE_MINOR_VARIANT=${ENABLE_LLVMLIBC_MINOR_VARIANT}


I assume these CMake vars will be defined in another patch?

Yes.
ENABLE_LLVMLIBC_MINOR_VARIANT and LLVMLIBC_SUBARCHIVE_NAME are cache variables defined in this patch, with ENABLE_LLVMLIBC_MINOR_VARIANT defaulting to OFF and LLVMLIBC_SUBARCHIVE_NAME as empty.

The intent is to enable this later through the corresponding JSON files, which will come in a separate patch once we agree on the naming conventions used here. As it stands, this patch should not introduce functional changes because these new CMake controls are disabled by default.

vhscampos · 2026-06-25T10:16:48Z

+            ${common_llvmlibc_cmake_args}
+            -DLIBC_TARGET_TRIPLE=${target_triple}
+            -DLIBC_CONF_TIME_64BIT=ON
+            -DLIBC_CONF_ERRNO_MODE=LIBC_ERRNO_MODE_SHARED
+            -DLIBC_CONF_PRINTF_DISABLE_FLOAT=OFF
+            -DLIBC_CONF_PRINTF_FLOAT_TO_STR_USE_FLOAT320=ON
+            -DLIBC_CONF_PRINTF_MODULAR=ON
+            -DLLVM_CMAKE_DIR=${LLVM_BINARY_DIR}/lib/cmake/llvm
+            -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON
+            -DLLVM_ENABLE_RUNTIMES=libc
+            -DLLVM_LIBC_ALL_HEADERS=ON
+            -DLLVM_LIBC_FULL_BUILD=ON
+            -DLIBC_TEST_COMPILE_OPTIONS_DEFAULT=${llvmlibc_test_compile_options_default}
+            -DLIBC_TEST_LINK_OPTIONS_DEFAULT=${llvmlibc_test_link_options_default}
+            -DLIBC_TEST_CMD=${test_cmd}
+            -DLIBC_TEST_HERMETIC_ONLY=ON
+            -DLLVM_EXTERNAL_LIT=${external_lit_path}
+            -DLLVM_LIT_ARGS=${llvmlibc_lit_args}


Most of this is duplicated between the if and else branches. Is it possible to have a single ExternalProject_Add call, but decide between the required argument valuesusing the if-else?

Yeah, I agree. I’ve moved the layering-specific build/install commands into a small argument list, and now use a single shared ExternalProject_Add call for llvmlibc.

Just to clarify, there are two separate LLVM libc flows:

The normal/full libc.a build, including the subarchive build.

The variant builds, which only build llvmlibc-support.

llvmlibc-support is ATfE’s support layer under arm-software/embedded/llvmlibc-support. It builds artifacts such as libcrt0.a, libcrt0-none.a, libcrt0-semihost.a, and libsemihost.a.

So for this minor variant, even though we do not build libc.a, we still need the libc headers because llvm-libc-support depends on them.

vhscampos · 2026-06-25T10:17:16Z

+        add_custom_target(llvmlibc-support-build)
+        add_custom_target(llvmlibc-support-install)


These are also the same placeholder pattern as explained above

Add CMake cache options to control which runtime payloads are built and installed for layered variants. This allows llvm-libc variants to install only the required minor-variant payload, while also making compiler-rt, llvm-libc core archives, and llvm-libc support libraries independently selectable. These options are currently defined in CMake so the layering flow can be enabled, but they are expected to move into the variant JSON handling in a follow-up patch..

The CMake option passing to llvm libc should be LLVM_LIBC_ENABLE_MINOR_VARIANT to match the existing patterns in llvm libc.

Rename ENABLE_LLVM_LIBC_MINOR_VARIANT to ENABLE_LLVMLIBC_MINOR_VARIANT and LLVM_LIBC_SUBARCHIVE_NAME to LLVMLIBC_SUBARCHIVE_NAME to consistent with the naming patterns used in the ATFE.

1. Moved the Layering specific build/install commands into a small argument list and now use a single shared ExternalProject_Add call for llvmlibc 2. Changed the help text to avoid the vague word “core”. 3. ENABLE_COMPILER_RT_LIBS also enables the install step for compiler-rt, so the description should say “Build and install” for consistency.

Avoid creating placeholder runtime targets when compiler-rt, compiler-rt-profile, or llvmlibc support libraries are disabled. Only schedule runtime subtargets that are actually built, and add ENABLE_COMPILER_RT_LIBS across the variant definitions.

simpal01 requested a review from a team as a code owner June 9, 2026 15:14

simpal01 changed the title ~~[ATFE] Add controls for layered runtime payloads~~ [ATFE] Add build controls for layered runtime payloads Jun 10, 2026

voltur01 reviewed Jun 11, 2026

View reviewed changes

Comment thread arm-software/embedded/arm-runtimes/CMakeLists.txt

vhscampos reviewed Jun 25, 2026

View reviewed changes

simpal01 added 5 commits July 1, 2026 21:28

fixup! [ATFE] Add controls for layered runtime payloads

8579ab2

The CMake option passing to llvm libc should be LLVM_LIBC_ENABLE_MINOR_VARIANT to match the existing patterns in llvm libc.

fixup! [ATFE] Add controls for layered runtime payloads

d91524c

Rename ENABLE_LLVM_LIBC_MINOR_VARIANT to ENABLE_LLVMLIBC_MINOR_VARIANT and LLVM_LIBC_SUBARCHIVE_NAME to LLVMLIBC_SUBARCHIVE_NAME to consistent with the naming patterns used in the ATFE.

simpal01 force-pushed the variant-specific-payload-install branch from 2f06513 to d0053f0 Compare July 1, 2026 20:41

		add_custom_target(llvmlibc-support-build)
		add_custom_target(llvmlibc-support-install)

Uh oh!

Conversation

simpal01 commented Jun 9, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vhscampos Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

simpal01 Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

vhscampos Jun 30, 2026 •

edited

Loading

simpal01 Jun 29, 2026 •

edited

Loading