C Library Roadmap

[stephanosio]

This issue describes the future plans for the C library support in the Zephyr RTOS.

Tasks

• Add picolibc support as a module (RFC: Create a module for picolibc #44096)
• Make picolibc the default C library for Zephyr #49922
• Add comprehensive C library testsuite #51982
  • shall test the functional requirements of all supported C libraries to ensure that the C library meets the Zephyr expectations.
  • shall have common codebase for testing different C libraries (focus on testing standard C features).
• Add native Zephyr support in the newlib (Add Zephyr-specific target for toolchain components sdk-ng#350)
• Fix newlib conflicts with the Zephyr POSIX subsystem
• Enforce C99 inttypes usage (Enforce C99 inttypes usage for standard C functions #46032)

Resources

• Discussion on the scope of the Zephyr minimal C library: https://discord.com/channels/720317445772017664/954308485489786921/954339280363343883
• Discussion on the picolibc as alternative to the Zephyr minimal C library: https://discord.com/channels/720317445772017664/954339222146387978/954339226311352351

[stephanosio]

cc @keith-packard

[keith-packard]

Picolibc has an extensive internal test suite which started with the newlib test suite, has had numerous fixes applied and then extensions to validate newer standards versions. It could be made usable on non-picolibc targets. I've also hacked up the glibc source code to build against picolibc. That latter is all GPL, of course. Would it be reasonable to use those glibc bits for testing?

I do question the utility of working to fix newlib for greater Zephyr compatibility. As newlib is primarily used with Cygwin, there are very strict source and binary compatibility requirements which make any API changes very difficult to upstream. As picolibc already tracks newlib fixes outside of Cygwin support, it would be more useful to focus on improving picolibc's Zephyr support.

[keith-packard]

Which toolchains would need to be supported for picolibc to be used as the default C library? Picolibc currently works with Zephyr SDK, Crosstool-ng, and the GNU ARM Embedded Toolchain. It is known to not work with ARC MetaWare Development Toolkit. I don't know if it works with the Arm Compiler, the Cadence XCC compiler or the Intel oneAPI compiler. Given that the missing compiler support all appear to be licensed, if support for them is required, who can do the work?

[stephanosio]

Which toolchains would need to be supported for picolibc to be used as the default C library?

Only the Zephyr SDK, since most Zephyr users are using it and all the upstream testing is done using the Zephyr SDK.

Given that the missing compiler support all appear to be licensed, if support for them is required, who can do the work?

For the proprietary compilers, it would be up to whoever maintains the compiler support to make that work. These compilers usually come with their own (certified) C library, so the picolibc may not be of much interest to their users anyway.

[keith-packard]

Should we set up an 'allow list' in the picolibc configuration so that people don't try to use picolibc with the proprietary toolchains?

[stephanosio]

Continuing from #54190 (comment):

Building Zephyr for C11 should likely involve using a Kconfig option rather than setting a CMake property in an arbitrary CMakeLists.txt, but this should be investigated in any case.

A Kconfig value such as CONFIG_LIBC_STD_C11 or something along those lines would probably be smart.

@cfriedt Currently, the C language standard to use for compiling C source code is specified through the CSTD CMake global property, whereas the C++ language standard to use for compiling C++ source code is specified through the STD_CPPxx Kconfig choices (e.g. STD_CPP11).

I acknowledge that this is inconsistent and needs to be improved -- preferably by settling on the Kconfig-only selection (e.g. STD_C99, STD_C11, ...); but, I would like @tejlmand's input on this since he is often opinionated on what should be CMake variables vs. Kconfigs.