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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
