[rfc] add support for newlib with nano specs

[stevew817]

Context: Cortex M-class SoCs

A lot of M-class software is currently built with GCC and newlib-nano. In order to ease the transition of preexisting projects currently building with GCC for ARM embedded and using that toolchain's provided newlib with nano specs, it would be useful for the LLVM toolchain to ship an equivalent library. I did see that picolibc is the preferred standard library in this toolchain, but migrating to it requires changes in the software projects. By providing a nano version of newlib in LLVM for ARM, these projects could be compiled with both LLVM and GCC toolchains without requiring changes beyond the build flags.

Proposal: add a library called 'newlib-nano' or 'nanolib' to the library options which builds newlib with the flags that GCC uses, and release that library as an overlay package similar to the current newlib and llvmlibc pakages. I can do a PR for adding it to the CMake targets at least.

Even better would be compatibility with GCC's specs paradigm, but that is going to be a whole other amount of work.

[voltur01]

Hi Steven, thank you for suggesting this! The original thinking was that picolibc is based on newlib nano, so is roughly equivalent, however you are correct that it requires a bit of porting work.

We would be happy to review the patches to add another overlay package for newlib nano with one remark: we started moving the toolchain build scripts to the new unified Arm Toolchain repository where we will host both embedded and HPC Linux toolchains, see https://github.com/arm/arm-toolchain. It is the same build scripts, but put into their own folder https://github.com/arm/arm-toolchain/tree/arm-software/arm-software/embedded so it would be best to create the PR against that new location to avoid the need of migration from here to there.

In the future, we may want to see how this can be optimzed, e.g. have one package with both newlib variants, however this will need a different mechanism, than spec files, as it was discussed in LLVM community and decided that spec files was not a good fit.

[smithp35]

Some additional thoughts on how we might be able to have a single newlib overlay package. If we can end up with a directory layout like

aarch64-none-elf
|- aarch64a
|---lib
|-----newlib-nano
|------ libc.a libcrt0.a libsemihost.a
|---- libc.a    # non-nano
|---- libcrt0.a # non-nano
|---- libsemihost.a # non-nano
|---- libc++.a # shared between nano and non-nano

Then if we can use something like -fmultilib-flag=newlib-nano to add a "layer" so that we add the path to newlib-nano ahead of the path to standard newlib libraries.

As this would be improving newlib we could start with a separate newlib-nano package, but migrate to a single newlib overlay later. As long as users use a provided clang config file to select newlib nano, then this migration should be transparent as we can just update the config file with the new mechanism.