Keith Packard

> * nios2-zephyr-elf Picolibc already had nios2 support, it just needed fixing for multilib configurations to work around the gcc flags for FPU configuration which forcibly set -fsingle-precision-constants, breaking the...

Switching to LZMA gives us a temporary reprieve and doesn't change workflow for users, so it's a pretty simple choice to make. Moving forward, it's pretty clear we'll need a...

> If I understand correctly, you are adding support for additional TLS (Thread Local Storage) when using picolibc because picolibc uses the default one for managing internal per-task variables. Is...

This is now based on @aggarg 's generalized TLS support patch.

This PR is still valid -- it now sits atop your changes and adds picolibc-specific TLS support using your hooks.

> What do you think about moving this code to the application (i.e. FreeRTOSConfig.h)? This lets the application writer control which memory block is used for TLS - part of...

> Is there a specific value that we get by putting TLS memory next to stack in the first case? * On systems with an MPU, you can save an...

> Looks like an interesting debate. I will have to dive a bit deeper to offer an informed opinion. For now, I don't like creating a coupling between the kernel...

> Then we could separate the newlib and pico lib extensions into header files, and have them brought in using a similar mechanism....just a thought. An easy change would be...

I've updated this PR: 1. Pass pxTopOfStack to configINIT_TLS_BLOCK (picolibc needs this) 2. Restructure TLS definitions to place them in separate files (one per C library) 3. Remove use of...