Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add Zephyr-specific target for toolchain components #350

Open
3 of 16 tasks
stephanosio opened this issue Jul 1, 2021 · 8 comments
Open
3 of 16 tasks

Add Zephyr-specific target for toolchain components #350

stephanosio opened this issue Jul 1, 2021 · 8 comments
Assignees
@stephanosio
Labels
area: Binutils Issues related to GNU Binutils area: GCC Issues related to GCC (GNU Compiler Collection) area: libstdc++ Issues related to libstdc++ (GNU C++ Library) area: Newlib Issues related to Newlib (C Library) enhancement Meta A collection of features, enhancements or bugs RFC

Comments

@stephanosio
Copy link
Member

stephanosio commented Jul 1, 2021 •
edited
Loading

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:

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
  • Add Zephyr RTOS targets to GNU Binutils
  • 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 stephanosio self-assigned this Jul 1, 2021
@stephanosio
Copy link
Member Author

cc @galak @nashif @tejlmand @carlescufi

@stephanosio stephanosio mentioned this issue Jul 19, 2021
Closed
@stephanosio stephanosio mentioned this issue Aug 4, 2021
Closed
@stephanosio stephanosio mentioned this issue Sep 11, 2021
Closed
@stephanosio stephanosio mentioned this issue Oct 1, 2021
Closed
stephanosio added a commit to stephanosio/zephyr-sdk-ng that referenced this issue Dec 3, 2021
@stephanosio
config: Set SoC-specific vendor name for Xtensa targets
fdd6e14 
This commit updates the Xtensa target toolchains to include the SoC
name in the vendor part of the target triplet.

For example, The target triplet for the Xtensa toolchain targeting the
"Xtensa Sample Controller SoC" has been changed from
`xtensa-zephyr-elf` to `xtensa-sample_controller_zephyr-elf`.

Once the Zephyr-specific targets are implemented (see issue zephyrproject-rtos#350),
these target triples should be renamed to use the proper `arch-soc-os`
format (e.g. `xtensa-sample_controller-zephyr`).

Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
@stephanosio
Copy link
Member Author

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

@stephanosio stephanosio added area: Binutils Issues related to GNU Binutils area: GCC Issues related to GCC (GNU Compiler Collection) area: Newlib Issues related to Newlib (C Library) Meta A collection of features, enhancements or bugs area: libstdc++ Issues related to libstdc++ (GNU C++ Library) labels Feb 10, 2022
stephanosio added a commit to stephanosio/zephyr-sdk-ng that referenced this issue Feb 23, 2022
@stephanosio
config: Set SoC-specific vendor name for Xtensa targets
0c7f9ae 
This commit updates the Xtensa target toolchains to include the SoC
name in the vendor part of the target triplet.

For example, The target triplet for the Xtensa toolchain targeting the
"Xtensa Sample Controller SoC" has been changed from
`xtensa-zephyr-elf` to `xtensa-sample_controller_zephyr-elf`.

Once the Zephyr-specific targets are implemented (see issue zephyrproject-rtos#350),
these target triples should be renamed to use the proper `arch-soc-os`
format (e.g. `xtensa-sample_controller-zephyr`).

Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
@cfriedt
Copy link
Member

cfriedt commented Feb 23, 2022

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
Copy link

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.

nashif pushed a commit that referenced this issue Mar 1, 2022
@stephanosio @nashif
config: Set SoC-specific vendor name for Xtensa targets
141dd4f 
This commit updates the Xtensa target toolchains to include the SoC
name in the vendor part of the target triplet.

For example, The target triplet for the Xtensa toolchain targeting the
"Xtensa Sample Controller SoC" has been changed from
`xtensa-zephyr-elf` to `xtensa-sample_controller_zephyr-elf`.

Once the Zephyr-specific targets are implemented (see issue #350),
these target triples should be renamed to use the proper `arch-soc-os`
format (e.g. `xtensa-sample_controller-zephyr`).

Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This was referenced Mar 18, 2022
Open
Closed
@lgl88911
Copy link

lgl88911 commented Apr 3, 2022

@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
Copy link
Member Author

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
Copy link

lgl88911 commented Apr 9, 2022 •
edited
Loading

@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
Copy link
Member

cfriedt commented Apr 11, 2022 •
edited
Loading

@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:

This was referenced May 19, 2022
Open
Open
@stephanosio stephanosio mentioned this issue Jul 11, 2022
Merged
@cfriedt cfriedt mentioned this issue Sep 10, 2022
Closed
@stephanosio stephanosio mentioned this issue Oct 4, 2022
Closed
@stephanosio stephanosio mentioned this issue Oct 9, 2022
Closed
@cfriedt cfriedt mentioned this issue Oct 12, 2022
Open
@cfriedt cfriedt mentioned this issue Oct 29, 2022
Merged
@stephanosio stephanosio mentioned this issue Dec 4, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@stephanosio stephanosio

Labels
area: Binutils Issues related to GNU Binutils area: GCC Issues related to GCC (GNU Compiler Collection) area: libstdc++ Issues related to libstdc++ (GNU C++ Library) area: Newlib Issues related to Newlib (C Library) enhancement Meta A collection of features, enhancements or bugs RFC
Projects
Zephyr SDK
Status: Todo
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cfriedt @lgl88911 @chrisc11 @stephanosio