Re: _REENT_CHECK_VERIFY calls __assert_func even if NDEBUG is defined
"R. Diez via Newlib" <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
> If you're tight on RAM, you might look at the newlib fork, picolibc, > which uses native TLS support for reentrant data values like > _rand_next. With that approach, your thread-local storage contains only > values used by your application and malloc need never be called. In this > case, the per-thread data would be only eight bytes. I do have one microcontroller with 8 KiB SRAM. For all others I do not want to bother. I am interested in your "only eight bytes" claim. Say I use picolibc, and then my firmware wants to use rand(), which needs many more bytes for the state of the pseudo-random number generator. The firmware is bare metal (no operating system). I guess there will not be a native TLS support then. How does rand() get the memory it needs? Do I need to preallocate it statically? Or have a separate memory pool for the TLS? Do I need to implement TLS myself? Can you do that with some sort of easy-to-code stack? Regards, rdiez