[PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Chris Johns]

On 11/9/20 12:40 am, Joel Sherrill wrote:
> How is the user/system integrator supposed to figure out the size of the TLS? It
> is not known until the application is linked and thus varies based on the total
> set of code linked. 

Yes the user links the application and inspects the executable with rtems-exeinfo:

$ rtems-exeinfo -T riscv-rtems6/c/griscv/testsuites/sptests/sptls01.exe
exe: riscv-rtems6/c/griscv/testsuites/sptests/sptls01.exe

Compilation:
 Producers: 2
  |  GNU AS 2.35.50: 5 objects
  |  GNU C17 10.2.1 20200904 (RTEMS 6, RSB
31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982): 241 objects
 Common flags: 2
  | -march=rv32imafd -mabi=ilp32d

TLS size      : 1
    data size : 1
     bss size : 0
    alignment : 1
    data addr : 0x400106b8

This is equivalent to how we manage stacks. For stacks you need to run the code
with an oversized stack, check the usage under all test conditions and then
derate by increasing the size by a % amount. TLS can be more accurate because
you link, have a look and then adjust your size then link again.

> As far as I can tell, this makes this type of task creation unsuitable for use
> in libraries where the end system is unknown.

Yes it is unsuitable and this is the problem with an API call, once we introduce
it we have no control over now it will be used.

I should also point out I will be less sympathetic to early adopters of this
call if we need to change things to make it more robust.

> It is at least fragile in tightly controlled applications and subject to someone
> guessing a number larger than required which wastes memory and goes against the
> intent of the statically allocated thread resources.

Sebastian and I discussed a disable for the call that needs to be enabled via
confdefs.h for the call to work. The idea is to catch any hidden usage.
Sebastian did not like this. Considering this some more I wonder if the TCB
should have a flag set to say the allocator was "static". This could be reported
by the `task` command and may be even via an API call. Users could then inspect
and check their system.

> If there is a practical and portable way to know this number, it needs to be
> explained quite well in the documentation and always used in any tests or examples.

Or an error is reported if the call sees a problem with the resource allocation.

Chris