On 20.07.22 22:52, Chris Johns wrote:
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?
You mean a proper sb-set-builder option and not just a
--with-newlib-tls? I would make it the default for the targets with
known to work TLS support: aarch64, arm, nios2, powerpc, riscv, and
sparc. For m68k we have a GCC code generation issue currently.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
