On 20/7/2022 6:20 pm, Sebastian Huber wrote: > On 20/07/2022 10:11, Chris Johns wrote: >>>> Are these TLS allocations in newlib based on a single use of a newlib call >>>> that >>>> brings in the reent stuff? How does that work? >>> No, each TLS object is defined in the translation unit which uses the >>> object. >>> The goal is to get only those objects linked in which are needed. >>> Currently, the >>> Newlib thread delete hook pulls in some objects, however, this dependency >>> will >>> go away once the TLS destructors are implemented. >> If I have task A and it opens a file and writes something to a file system >> will >> it pull in the TLS support for files? > > Yes. > >> Given the TLS support is static does this mean all threads in the A app >> allocate >> the newlib file TLS variables even if they never use newlib? > > Yes. > >> >> My understanding of the existing reent support is tasks that do not use >> newlib >> it never allocate a reent struct? > > No, the struct _reent is allocated for all tasks if you don't use > CONFIGURE_DISABLE_NEWLIB_REENTRANCY (which is not recommended). How would you > know if a task doesn't use Newlib?
I thought the get would do a check and then allocate on first use. It has been many years since I looked at the implementation. I think this change is a good one because it will reduce the needed memory to the amount used and it will have better performance. I think option you post is a good thing to add, maybe as --enable-newlib-reent-tls. What will be the default? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel