Fork newlib

[stephanosio]

Consider forking newlib and pulling it in the zephyr-crosstool-ng so as to facilitate Zephyr-specific development of the newlib.

This will be necessary as we implement more advanced OS features.

TODO: Compile rationale for forking newlib.

[stephanosio]

NOTE: The Zephyr Xtensa targets use a fork of newlib that is based on a very old version of newlib and contains Xtensa-specific patches.

In order to properly maintain the Zephyr-specific fork of newlib, these patches must be reworked/rebased.

[stephanosio]

cc @pfalcon

[pfalcon]

@stephanosio: What's this project at all? Is it essentially your personal dumping ground for things not yet ready for upstream? I'd otherwise expect such a ticket to be opened in https://github.com/zephyrproject-rtos/sdk-ng .

NOTE: The Zephyr Xtensa targets use a fork of newlib that is based on a very old version of newlib and contains Xtensa-specific patches.

I'd say that would be a litmus test whether we're ready to fork newlib: would we be able to upgrade Xtensa target without (much) help from @jcmvbkbc (re: not much progress in zephyrproject-rtos/sdk-ng#64).

[stephanosio]

What's this project at all? Is it essentially your personal dumping ground for things not yet ready for upstream?

@pfalcon This is something that will potentially replace sdk-ng; see #25 (comment).

I'd say that would be a litmus test whether we're ready to fork newlib: would we be able to upgrade Xtensa target without (much) help from @jcmvbkbc (re: not much progress in zephyrproject-rtos/sdk-ng#64).

I had a quick glance at the patches, and it seemed rebasing them on top of the newlib 3.x release should be easy enough. I will probably take a look later if @jcmvbkbc doesn't have time to do so.

[pfalcon]

I had a quick glance at the patches, and it seemed rebasing them on top of the newlib 3.x release should be easy enough.

That would be my guess, even without looking at them: I can't imagine what would there so Xtensa-specific and so not upgradable. If there would be problems with applying them on the recent Newlib version right away, I would try series of interim rebases thru a few of intermediate Newlib revisions, to better pick up any Newlib's own changes which may affect the patches. The meat of the work would be of course testing the results.

Just to make it said: I can't imagine myself doing/actively helping with e.g. this upgrade, unless specifically assigned to such a task, and then I already have enough enough assignments and backlog tasks in them. So, hopefully you have the bandwidth, or this is going to be in more wide planning before the decision to push a button.

Thanks for the responses and keeping in loop otherwise!

[jcmvbkbc]

I've pushed the most recent version of the xtensa patches I've been working on to the xtensa-3.2.0 branch in my https://github.com/jcmvbkbc/newlib-xtensa.git tree. I don't have the power to push it myself upstream.

[galak]

I've pushed the most recent version of the xtensa patches I've been working on to the xtensa-3.2.0 branch in my https://github.com/jcmvbkbc/newlib-xtensa.git tree. I don't have the power to push it myself upstream.

@jcmvbkbc thanks so much. Can you say what level of testing these changes have gone through?

[jcmvbkbc]

what level of testing these changes have gone through?

There haven't been any.

[stephanosio]

what level of testing these changes have gone through?

There haven't been any.

@galak We can try running the newlib testsuite in the QEMU.

There needs to be some form of QA process for the toolchain releases, and I think this would be a good first step: #13

[galak]

I created https://github.com/zephyrproject-rtos/newlib-cygwin and rebased @jcmvbkbc on newlib-3.3.0 as well as pulled in the few Zephyr specific patches. These are on 2 different branches as the new xtensa ones would conflict for other arch's from a quick glance.

[igrr]

@jcmvbkbc do you see any issues (licensing or any other) with sending a rebased version of your xtensa-3.2.0 branch to newlib mailing list? Given that Xtensa support is already present in picolibc, there is a good chance it could be accepted into newlib.

[jcmvbkbc]

Licensing -- not that I know of, any other -- maybe whether it builds and works correctly.