Support 'nano' runtime libraries #1279
Conversation
|
NOTE: The following must be set in order to build the 'nano' runtime libraries:
|
|
|
This commit adds the patches for the series of commits required to support building the 'nano' variant of C/C++ runtime libraries. This is a temporary commit and should be removed once the upstream PR gets merged (see crosstool-ng/crosstool-ng#1279). Signed-off-by: Stephanos Ioannidis <[email protected]>
|
CI result for this patch on Zephyr SDK repository: |
NEWLIB_LIBC_NANO was defined only for gnuarmemb toolchain because Zephyr SDK did not support the newlib nano variant (as defined by nano.specs) due to the inherent limitations of crosstool-ng, which is used to build the toolchains. Since crosstool-ng/crosstool-ng#1279 added support for the nano C/C++ runtime library variant and this change was introduced to the Zephyr SDK through zephyrproject-rtos#153, it is no longer necessary to restrict the newlib nano variant to gnuarmemb toolchain only. Signed-off-by: Stephanos Ioannidis <[email protected]>
stephanosio
force-pushed
the
newlib_nano_variant
branch
from
a25b9af to
6f47e34
Compare
|
Force pushing to allow optional target toolchain library stripping using |
This commit adds the patches for the series of commits required to support building the 'nano' variant of C/C++ runtime libraries. This is a temporary commit and should be removed once the upstream PR gets merged (see crosstool-ng/crosstool-ng#1279). Signed-off-by: Stephanos Ioannidis <[email protected]>
|
Gonna try this PR when I got some time. Got some comments: in regards to the commit Further the strip target files doesn't really fit in this PR, and I don't see why you would not just build the target files with |
IIRC, there was something weird happening when I did that initially. This was while I was trying to fix multiple problems at once, so I will check again and see if it works now.
I put it here mainly because the unstripped libs were simply too big and, with the multilibs and the additional nano variant, it was adding hundreds of megabytes to the final toolchain package. If you prefer, I could move this commit to a separate PR.
Thanks to That aside, the gcc (and other GNU toolchains) people seem to think that all runtime libs should be initially built with debugging information and stripped later if necessary, so I thought I would make it go with that flow. A similar discussion was made in the newlib mailing list (which uses the same build system as gcc):
One problem with This is also the way it is done in the GNU ARM Embedded build script (i.e. using I am not aware of any way to force |
stephanosio
force-pushed
the
newlib_nano_variant
branch
from
6f47e34 to
6fca474
Compare
Simply prepending Force pushing to address this. |
This commit adds the patches for the series of commits required to support building the 'nano' variant of C/C++ runtime libraries. This is a temporary commit and should be removed once the upstream PR gets merged (see crosstool-ng/crosstool-ng#1279). Signed-off-by: Stephanos Ioannidis <[email protected]>
Just to avoid misunderstanding, I am not maintainer of this project. I think however that small PR will get included faster.
Not possibe to append CFLAGS after that? There often are EXTRA Flags that come after, and options like
Not really unreasonable, I like this aswell so I can split the debuginfo into separate files and install as needed.
When do you need stack-unwinding? From the program itself you should use .ARM.exidx with
The sections might vary across architectures/versions, I would make a special case for ARM (etc) that arent served well with strip. |
This commit adds the patches for the series of commits required to support building the 'nano' variant of C/C++ runtime libraries. This is a temporary commit and should be removed once the upstream PR gets merged (see crosstool-ng/crosstool-ng#1279). Signed-off-by: Stephanos Ioannidis <[email protected]>
This commit adds a patch for supporting the newlib retargetable locking configuration in the crosstool-ng. The patch is derived from the upstream pull request for the retargetable locking configuration (crosstool-ng/crosstool-ng#1284) cherry-picked on top of the newlib nano variant pull request (crosstool-ng/crosstool-ng#1279). The work branch for this patch is available at the following location: stephanosio/crosstool-ng/newlib_nano_variant_with_retargetable_locking Signed-off-by: Stephanos Ioannidis <[email protected]>
This commit adds the new configuration option 'LIBC_NANO_NEWLIB' for specifying the additional 'nano' variant of newlib to be built. In addition, the existing newlib 'LIBC_NEWLIB_...' configs are mirrored as 'LIBC_NANO_NEWLIB_...' in order to accommodate specifying different build configurations for the nano variant. For more details, refer to the issue zephyrproject-rtos/sdk-ng#152. Signed-off-by: Stephanos Ioannidis <[email protected]>
This commit updates the newlib build script to build the additional newlib nano variant using the nano variant-specific build options. Signed-off-by: Stephanos Ioannidis <[email protected]>
This commit adds the new configuration option 'CC_GCC_LIBSTDCXX_NANO'
for specifying the additional 'nano' variant of libstdc++ to be built
and updates the gcc build script to build the stdlibc++ nano variant
with the '-Os' (optimise for size) option flag.
The libstdc++ nano variant (lib{std,sup}c++_nano.a) is specified by
'nano.specs' alongside the libc nano variant (lib{c,g}_nano.a).
Signed-off-by: Stephanos Ioannidis <[email protected]>
The gcc target libraries (e.g. libstdc++) are currently built without any optimisation flag when 'CT_CC_GCC_ENABLE_TARGET_OPTSPACE' is not enabled and default to '-O0' unless user explicitly specifies an optimisation flag. This commit updates the gcc build script to assume '-O2' for building target libraries unless user provides a different optimisation flag. Note also that this is the default behaviour for gcc when C[XX]FLAGS_FOR_TARGET is not overridden. Signed-off-by: Stephanos Ioannidis <[email protected]>
This commit adds an option to strip the target toolchain libraries (e.g. libc, libstdc++) of any unneeded or debugging information. Stripping is enabled by default as it is often desirable to reduce the overall toolchain size when producing a release. Signed-off-by: Stephanos Ioannidis <[email protected]>
stephanosio
force-pushed
the
newlib_nano_variant
branch
from
6fca474 to
14d6aa0
Compare
|
Force pushing to resolve merge conflict with #1284 (added retargetable locking configuration for the nano variant as well). |
| if [ "${CT_LIBC_NANO_NEWLIB_IO_FLOAT}" = "y" ]; then | ||
| newlib_opts+=( "--enable-newlib-io-float" ) | ||
| if [ "${CT_LIBC_NANO_NEWLIB_IO_LDBL}" = "y" ]; then | ||
| newlib_opts+=( "--enable-newlib-io-long-double" ) | ||
| else | ||
| newlib_opts+=( "--disable-newlib-io-long-double" ) | ||
| fi |
There was a problem hiding this comment.
-
I think that this kind of dependencies between LIBC_NANO_NEWLIB_IO_FLOAT and LIBC_NANO_NEWLIB_LDBL is better expressed in the Kconfig. They predated the introduction of
yn_args, but if they start to propagate, there is no reason not to fold them into this array. -
I don't like that the yn_args variable is global. Granted, it was like that before - this was concealed by having it defined and used by the same function. But I'd prefer having a single list of all newlib options - if necessary, with the third field identifying whether this flag is applicable to the normal variant of newlib, or to the nano variant, or to both. If it must be global, name it in a way that avoid clashes with other components.
-
I'd prefer the names of the new variables to start with NEWLIB_NANO rather than NANO_NEWLIB. After all, this is still a part of the newlib configuration.
-
I must be missing something, but I don't see how this new code builds the "nano" variant while the existing code builds a "full" library. The only differences I see are the names of the options governing the newlib configuration. Can you explain? If there is some difference, it should be highlighted with a comment in the code. Moreover, I think that both variants can be handled by the same backend, just have newlib_main_full/newlib_main_nano pass the necessary bits to that backend, e.g.:
newlib_main_full()
{
newlib_main_backend NEWLIB
}
newlib_main_nano()
{
newlib_main_backend NEWLIB_NANO
}
newlib_main_backend()
{
local kcfg_prefix=$1
...
for ynarg in $yn_args; do
var="CT_LIBC_${kcfg_prefix}_${ynarg%:*}"
...
}
There was a problem hiding this comment.
ad 4.: nano is just a set of libraries with different options which you can pick at compile time. Linaro, ARM and many ARM Toolchains offer them, look at https://github.com/FreddieChopin/bleeding-edge-toolchain for example.
There is no difference to a full toolchain, but you don't need to compile twice for host.
| fi | ||
|
|
||
| # Assume '-O2' by default for building target libraries. | ||
| cflags_for_target="-g -O2 ${cflags_for_target}" |
There was a problem hiding this comment.
I think this should be the default for TARGET_CFLAGS in Kconfig, this will be more obvious to the user. Needs to be tested more thoroughly, though, as it will affect not just gcc build.
There was a problem hiding this comment.
An argument against that would be that someone like me could expect the flags work identical to "manual" builds.
With empty flags: pick the packages defaults (which might well be different).
Prepending the package defaults seems so be the most sane to me, as you could eg. easily disable debugging info with -g0 while leaving the respective optimization defaults untouched, or adding -flto for adding LTO info.
Then maybe we can fixup all the small deficiencies and differences in packages, see #1267, #1270, #1280
This commit adds a patch for supporting the newlib retargetable locking configuration in the crosstool-ng. The patch is derived from the upstream pull request for the retargetable locking configuration (crosstool-ng/crosstool-ng#1284) cherry-picked on top of the newlib nano variant pull request (crosstool-ng/crosstool-ng#1279). The work branch for this patch is available at the following location: stephanosio/crosstool-ng/newlib_nano_variant_with_retargetable_locking Signed-off-by: Stephanos Ioannidis <[email protected]>
|
Just FYI, GCC might be aware of t least "nano-formatted-io" (see #1437). I'm not saying above "feature" of the GCC should stop us from building nano flavors of run-time libs along with their "normal" counterpart, but given said mismatch (between Newlib & GCC) leads to additional 22 failures in GCC's DejaGnu suit (see below), it might need some love to get fixed and not fool people looking at regressions. These're those extra failures for the case of Newlib configured with And BTW @stephanosio, @galak do you have any interest in resurrecting your work on this one anytime soon? |
|
I've proposed a different PR that makes newlib-nano into a companion library so that you can build multiple C libraries and select which one you want when building applications. The initial PR, #1444, adds picolibc as a companion library, but once we decide if that's the right way forward, and get that fixed up and merged, then adding newlib-nano is all ready to go. |
|
@keith-packard, @cpackham now #1444 is merged. Any hints on what needs to be done for moving a special "nano" flavor of Newlib into companion libs? |
|
I've got something that builds in my nano-companion branch, but I haven't managed to test it yet as I'm having trouble building the zephyr configuration of crosstool-ng due to python package version differences. If you want to explore that, please look here: https://github.com/keith-packard/crosstool-ng/tree/nano-companion |
what's the python issue you are running into? |
Looks like something is looking for python3.8, but that version isn't working correctly in my debian unstable environment: |
|
Got everything nicely built from https://github.com/keith-packard/crosstool-ng/tree/nano-companion and see a second instance of Newlib libs in And thanks to auto-generated |
Ah, we build a version of GDB with python3.8 support. I'd suggest to just disable GDB being built as its not related to the newlib. |
I changed the python3.8 invocation to just use python3 and it worked just fine. Maybe improving crosstool-ng to allow for 'python >= 3.8' somehow would be useful? |
Cool! Now to figure out if the resulting toolchain is actually useful :-) |
|
May we close this now with #1447 merged? |
Ditto. I think this can be closed out. |
|
The consensus seems that we can close this. |
7 participants
This PR includes a series of commits required to support building the 'nano' variant of C/C++ runtime libraries (using newlib; other libc support can be added in the future using a similar method).
The 'nano' runtime libraries are specified by the
nano.specsfile and are often included in embedded toolchains (e.g. GNU ARM Embedded) for memory-constrained target devices.The following is a brief summary of the changes introduced by this PR:
Add nano variant-specific newlib configurations in
config/libc/newlib.in.LIBC_NEWLIB_...configs as is. These configurations will be used to build the normal variant (lib{c,g}.a).LIBC_NEWLIB_...configs toLIBC_NANO_NEWLIB_...configs. These configurations will be used to build the nano variant (lib{c,g}_nano.a).Modify newlib build script to build
LIBCandLIBC_NANOvariants separately.Build an additional libstdc++ with
-Os(optimise for size) and place it aslib{std,sup}c++_nano.a(the default libstdc++ is built with-O2).Strip debug information from the built libraries.
Refer to the following issues for the rationale of supporting both normal (non-nano) and nano variants: zephyrproject-rtos/sdk-ng#151
This PR supersedes #1225, which only renames the default runtime libraries to comply with
nano.specswithout actually building a separate nano variant.