configs: common: enable c++11 thread support via c11 threads

[cfriedt]

trafficstars

Notes for Revision 2

[!NOTE] This is the second revision of this change, the first being in https://github.com/zephyrproject-rtos/sdk-ng/pull/735.

This revision adds a weak default implementations of C11 <threads.h> API functions, so that Zephyr applications can continue to build and link with default settings (i.e. without enabling the options below):

CONFIG_COMMON_LIBC_THRD=y
CONFIG_POSIX_API=y
CONFIG_DYNAMIC_THREAD=y
CONFIG_THREAD_STACK_INFO=y

Overview

This change allows Zephyr developers to use most or all of the C++ facilities in gcc that depend on gthread support.

Those facilities include (but are likely not limited to)

• std::thread
• std::this_thread
• std::mutex
• std::recursive_mutex
• std::shared_mutex
• std::condition_variable
• std::binary_semaphore
• std::counting_semaphore
• std::lock_guard
• std::unique_lock
• std::scoped_lock
• std::shared_lock
• std::syncstream
• std::future
• std::async

Associated Zephyr SDK PRs

• [x] https://github.com/zephyrproject-rtos/gcc/pull/27
• [x] https://github.com/zephyrproject-rtos/crosstool-ng/pull/27
• [x] https://github.com/zephyrproject-rtos/newlib-cygwin/pull/7

Associated Zephyr PRs

• [x] https://github.com/zephyrproject-rtos/zephyr/pull/69912
• [ ] https://github.com/zephyrproject-rtos/zephyr/pull/43729

Zephyr SDK Toolchain Snapshots

• [x] aarch64-zephyr-elf
• [ ] arc64-zephyr-elf
• [ ] arc-zephyr-elf
• [x] arm-zephyr-elf
• [ ] microblazeel-zephyr-elf
• [ ] mips-zephyr-elf
• [ ] nios2-zephyr-elf
• [x] riscv64-zephyr-elf
• [x] x86_64-zephyr-elf
• [ ] xtensa*-zephyr-elf

Testing branch

Test are in review at https://github.com/zephyrproject-rtos/zephyr/pull/43729 .

The test suites can be run with e.g.

west build -p auto -b qemu_riscv64 -t run tests/lib/cpp/std/thread \
  -- \
  -DCONFIG_PICOLIBC=n \
  -DCONFIG_NEWLIB_LIBC=y

They should run via picolibc eventually as well, but IIRC, there is an error about a missing .spec file. The workaround is to copy the spec file from a separate Zephyr SDK installation.

Help Wanted

Updating Picolibc

The few changes required to newlib might also need to be applied to picolibc in order to expose similar functionality.

Additional Testsuites

It would be helpful to add test suites for the following

• std::semaphore
• std::future
• std::coroutine

Additional testsuites can be added in parallel. They should not be considered blockers by any means, since they do not depend on anything specific to Zephyr.

Technically, not dependent on threading, coroutine support in Zephyr might Just Work (TM). However, coroutines have the potential to be extremely impactful in Zephyr as they are far more memory efficient than threads (important for resource-constrained devices).

Building, Testing, and Uploading Additional SDK Toolchains

"Zephyr SDK Toolchain Snapshots" lists a number of unchecked boxes and unlinked toolchains without links. To check the box and populate the link, the following steps should be taken:

1. Build the toolchain

sh ./sdk-ng/contrib/linux_build_toolchain.sh -o /tmp/sdk-build -c $ARCH-zephyr-elf

2. Back up the existing toolchain (one-time only)

rsync -avr /opt/zephyr/zephyr-sdk-0.16.8/$ARCH-zephyr-elf{,_orig}/

3. Overwrite the old toolchain with the new

rsync -avr --delete {/tmp/sdk-build/output,/opt/zephyr/zephyr-sdk-0.16.8}/arc64-zephyr-elf/

4. Ensure the following testsuites build, run, and pass

west build -p auto -b $BOARD -t run tests/lib/cpp/std/condition_variable/ -- -DCONFIG_NEWLIB_LIBC=y -DCONFIG_PICOLIBC=n
west build -p auto -b $BOARD -t run tests/lib/cpp/std/mutex/ -- -DCONFIG_NEWLIB_LIBC=y -DCONFIG_PICOLIBC=n
west build -p auto -b $BOARD -t run tests/lib/cpp/std/thread/ -- -DCONFIG_NEWLIB_LIBC=y -DCONFIG_PICOLIBC=n

5. Compress the toolchain

cd /opt/zephyr/zephyr-sdk-0.16.8
tar cpJf ~/$ARCH-zephyr-elf.tar.xz $ARCH-zephyr-elf

6. Upload file to Google Drive
7. Update Link

LLVM Toolchain Integration

Currently, all of this work is being done against Zephyr's GCC-based SDK toolchains. It's possible that LLVM toolchain integration will be much easier.

Our testsuites should run successfully with both GCC-based toolchains as well as with LLVM.