[PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Sebastian Huber]

Hello Joel,

this configuration option is a by product of the discussions related to 
the proposed rtems_task_create_from_config() directive. I addresses an 
issue with thread-local storage in dynamically linked objects. Since I 
work currently in the same code area, it is easier if I try to implement 
it instead of Chris.

​https://lists.rtems.org/pipermail/devel/2020-September/061867.html

On 10/09/2020 16:40, 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.
One way to figure out the TLS size is to link the executable and look at 
the _TLS_Size symbol. We could also add an API function to get the size.
>
> 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, the rtems_task_create_from_config() is unsuitable for general 
purpose libraries.

>
> 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.

I talked with Chris today and we suggest to add this member to the task 
configuration:

+  /**
+   * @brief This member defines the maximum thread-local storage size 
supported
+   *   by the task storage area.
+   *
+   * If the value is less than the actual thread-local storage size, 
then the
+   * task creation by rtems_task_create_from_config() fails.
+   *
+   * If the value is less than the task storage area size, then the 
task creation by
+   * rtems_task_create_from_config() fails.
+   */
+  size_t maximum_thread_local_storage_size;

So, if the task configuration doesn't match with the actual TLS size, 
then you get run-time errors during task creation.

I work currently on a v4 of the rtems_task_create_from_config() patch.

>
> 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.
The TLS size is only relevant if you use rtems_task_create_from_config() 
or dynamically linked objects with thread-local storage. There is no 
need to spread this stuff all over the place.