Newlib has no synchronization

[andyross]

I can't find any implementation of locking or synchronization hooks for newlib.

I bumped into what I thought briefly was a SMP race in newlib malloc (it wasn't) and went looking to be sure that we were doing the locking correctly. And... we aren't?

I see that this was filed a year and a half ago (which is inexplicably an Enhancement and not a Bug): #21519 and was seemingly addressed by #21518 , which never merged.

The relevant hooks (e.g. __malloc_lock) are indeed compiled into our newlib libc.a binaries, but it looks like they also contain a weak fallback stub that just noops.

Am I wrong, or did we drop this? Without locking newlib's heap and stdio layers are fundamentally unsafe in any context that can be preempted, which is... mostly useless (especially when compared to our own heap and console layers that are threadsafe, SMP-aware and interrupt clean!).

[andyross]

Add @stephanosio and @kaidoho who were involved earlier. Am I just looking in the wrong place?

[stephanosio]

Am I wrong, or did we drop this? Without locking newlib's heap and stdio layers are fundamentally unsafe in any context that can be preempted, which is... mostly useless

@andyross That is indeed the case. #21518 (comment) This sort of died out because nobody really pursued it.

p.s. this does sound like something that needs to be addressed before LTS ...

[kaidoho]

Hi, I've never received a response to

#21518 (comment)

fixing the issues with newlib has always been just a tiny bit of a bigger picture. To make Zephyr OS applicable for the company I am with, I require full scale C++ Support. Thus I ended up cross-compiling the Zephyr toolchain for hours, days, nights trying to figure out what the guys from RTEMS did, and trying to port it for Zephyr. As a loosely coupled hobbyist, I can't turn such a big wheel on my own, cross-compiling toolchains for n architectures with a build mechanism that was just recently introduced back then, testing, discussing details - neither I felt the project fully understood that there's a critial issue residing in the OS / Toolchains, nor that it is very eager to have a working C++ Support. It has certainly been my mistake to stop work without notification.

From my point of view, this issue, as well as, improving C++ support needs a project lead and coordination between the various working groups.

[galak]

@kaidoho are you able to re-pick up your PR and see if we can get this to a state to merge?

[kaidoho]

@galak To be honest I am very busy at the moment. That's why it took me quite a few days to respond. Sure I am willed to contribute and will do that if it helps, but my work focused on ARM and there are a bunch of other architectures that need to be addressed. I think it would be good to have a commitment from the steering board that C++ Support is of importance / a project goal. Then, we could split this huge epic into feasable portions / steps - the first of them C / newlib. My problem was that the second step libstdc++ turned into a huge work package, linked to C/ newlib which I can't complete without directions and for all architectures.

I need to review what I've done so far, and how it matches Zephyr OS as it is today (haven't looked into it since then). Then I can put together a new RFC wrt. C++.

Yes we can pick up the PR, but wouldn't it be better to drop the PR and you take over?