Add Zephyr-specific target for toolchain components

[stephanosio]

trafficstars

Proposal

The Zephyr SDK toolchain components are currently built targeting the generic bare metal target (i.e. arm-*-eabi for AArch32 and (arch)-*-elf for the rest).

The generic bare metal target, as its name suggests, lacks proper OS-specific customisation and is therefore very limited in its capability to support the features that require close integration with the target operating system (e.g. synchronisation primitives, reentrancy, support for the standard library functions that require OS-specific implementation).

Here I propose to add the Zephyr RTOS-specific targets named (arch)-*-zephyr for the purpose of supporting more advanced features that require close OS integration.

The SDK toolchain components of interest at this time are the following:

• GNU Binutils
• GNU Compiler Collection (GCC)
• Newlib
• GNU C++ Library (part of GCC; aka. libstdc++)

The primary goal of this is as follows:

• Provide consistent type system across Zephyr targets (see https://github.com/zephyrproject-rtos/zephyr/issues/37718#issuecomment-917435777)
• Support reentrancy in newlib
• Support system calls and better POSIX layer implementation in newlib (see https://github.com/zephyrproject-rtos/zephyr/issues/13787)
• Support thread safety and reentrancy in libstdc++
• Support OS-specific primitives in libstdc++ (e.g. std::thread, std::mutex, ...)

Initially, this will be implemented by adding the component patches to the sdk-ng repository or the corresponding Zephyr fork repositories if they exist. Eventually, these patches will be upstreamed to the relevant upstream projects.

Progress

• [ ] Add Zephyr RTOS targets to config.sub
  • [x] Implemented
  • [ ] Merged into sdk-ng
  • [x] Merged upstream
• [ ] Add Zephyr RTOS targets to GNU Binutils
  • [x] Implemented
  • [ ] Merged into sdk-ng
  • [ ] Merged upstream
• [ ] Add Zephyr RTOS targets to GNU Compiler Collection (GCC) and C++ Library
  • [ ] Implemented
  • [ ] Merged into sdk-ng
  • [ ] Merged upstream
• [ ] Add Zephyr RTOS targets to Newlib
  • [ ] Implemented
  • [ ] Merged into sdk-ng
  • [ ] Merged upstream

[stephanosio]

cc @galak @nashif @tejlmand @carlescufi

[stephanosio]

Re: libstdc++ thread safety

• libstdc++ internally uses the gthread implementation provided by the libgcc.
• Support --enable-threads=zephyr

gthread interface definition: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libgcc/gthr.h gthread interface implementation for RTEMS: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libgcc/config/gthr-rtems.h std::mutex implementation using gthread: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/include/bits/std_mutex.h mutex: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/include/std/mutex

[cfriedt]

Re: libstdc++ thread safety

• libstdc++ internally uses the gthread implementation provided by the libgcc.
• Support --enable-threads=zephyr

gthread interface definition: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libgcc/gthr.h gthread interface implementation for RTEMS: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libgcc/config/gthr-rtems.h std::mutex implementation using gthread: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/include/bits/std_mutex.h mutex: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/include/std/mutex

I started trying to get C++ thread and mutex support working some time ago. One of the major challenges (especially for std::thread) is the idea of dynamically created (user) thread stacks.

I'm 100% interested in helping to support this feature.

[chrisc11]

For newlib, just wanted to note that one other item that would be very useful if a version winds up getting compiled specifically for Zephyr would be emit debug information by adding the -g cflag to the compilation. Many times in the past, I've seen the lack of this flag (and re-entrancy) be big pain points for other targets like the newlib bundled with GNU Arm Embedded Toolchain releases.

This would not impact the final binary size since all debug info gets stripped for .bin generation and would greatly improve debug-ability by improving stack unwinds for issues that take place while in a newlib callchain and being able to easily decode internal newlib types.

[lgl88911]

@stephanosio May I ask if there is a specific completion time for "Add Zephyr RTOS targets to Newlib", and once it is completed does it mean that we can directly use newlib's posix instead of zephyr's posix subsystem? Thanks!

[stephanosio]

May I ask if there is a specific completion time for "Add Zephyr RTOS targets to Newlib"

No timeline yet; but, this will likely be implemented before this year ends.

once it is completed does it mean that we can directly use newlib's posix instead of zephyr's posix subsystem?

More like in conjunction with the Zephyr's POSIX subsystem. The newlib Zephyr port will be designed such that there are no conflicts with the Zephyr's POSIX subsystem, and also that it makes use of the Zephyr subsystem(s) where possible.

[lgl88911]

@stephanosio Thanks for reply!

More like in conjunction with the Zephyr's POSIX subsystem. The newlib Zephyr port will be designed such that there are no conflicts with the Zephyr's POSIX subsystem, and also that it makes use of the Zephyr subsystem(s) where possible.

Got it. When I want to link zephyr as a library and other source code files into an executable, even if the other files only use the posix API, I can't get rid of the dependency on the zephyr kernel header files.

[cfriedt]

@stephanosio - I would be happy to get the minimal libc in improved POSIX shape, although I believe Newlib is better for that. It still helps to have a relatively small c library in-tree.

I do agree that the minimal libc should be mostly header-compatible with newlib (see PR below, for example). However, I do not believe that Newlib needs to change much, if at all, to support POSIX in Zephyr.

Also std::thread and std::mutex are on my agenda. Just moving very slowly (see PR below). I think we should adopt gthr-posix.h, get that working, and then eventually optimize with gthr-zephyr.h which would then be moved upstream, in order to decouple C++ items from POSIX in Zephyr.

Relevant PRs:

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