Are there any plans to integrate Picolibc into the GCC toolchain?

[Scotty55]

It has many advantages over newlib and eliminates dynamic memory usage for printf and scanf of floating point data.

[Tesla DeLorean]

What's stopping you from linking whatever libraries you want?

[Scotty55]

So far as understood some discussions, thread level storage and locking has to be integrated with the operating system, e.g. FreeRtos or Azure/ThreadX. How do I do that with STs RTOS implementations?

[Tesla DeLorean]

For TLS that would be why you'd use the heap or stack rather than statics.

For context you'll have do that at a thread level, so yes the OS and perhaps at a register one too.

You could perhaps use a resource pool rather than the heap, but you'd need to guard against leaks.

[Scotty55]

Thank you for your response, but maybe I should explain my actual problem.

I need to implement a Json RPC interface listening to several communication channels. It should be able to handle floating point numbers, or we have to scale all data to integer which is here a rather complex problem.

The Json C++ library uses finally - of course - the low level C library functions to generate and parse strings and numbers. Newlib has a really awful float print and scan interface which uses dynamic memory. Picolibc is much better and doesn't use dynamic memory at all.

In both cases I need locking, because several threads are necessary to handle the communication. Newlib does this with the well known ******** code, and I am still not convinced that the actual ST toolchain provides a bullet proof implementation. Picolibc uses native Thread Level Storage and should avoid these problems.

Now, what do you recommend?