Support statically allocated threads

[Sebastian Huber]

In some applications it is desirable to have statically allocated resources for all operating system objects.

In addition to the thread control block, up to four memory areas are currently allocated by a thread:

1. stack area

2. TLS area

3. FP context

4. thread queue heads

Currently the FP context and the TLS area are separately allocated from the workspace. This complicates the workspace size estimate. Add the FP context and TLS size to the stack size and place them in the stack area. This makes it also possible to move the stack area allocation out of _Thread_Initialize(). Use a hook to get the thread queue heads which is configured depending on the unlimited objects option of the configuration.

Statically allocate the stacks for internal threads (e.g. idle and MPCI receive server) in a dedicated linker section (similar to the interrupt stacks). Mention this in the Classic API Guide configuration chapter.

[Chris Johns]

Does this assume TLS is a fixed size? I would need to revisit how TLS support would be managed in the dynamic loading situation. At a guess I suspect it will break possible soluitons and that concerns me. I would prefer we do not wedged libdl in to a corner with change for a use case I do not fully understand. Maybe a detailed use case would help.

[Sebastian Huber]

Nothing stops you from reallocating the TLS area on demand. In the worst case you waste a bit of memory. I don't think this change here will add constraints to libdl.

[Sebastian Huber]

For clarification, the pointer to the TLS area in the thread control block will remain as is.

[Chris Johns]

Great, that helps. Thanks.

[Joel Sherrill]

In at least two applications I have helped with that had custom allocators, this sounds like it might not work. They had special mmu permissions on their stack memory.

[Sebastian Huber]

I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread.

[Joel Sherrill]

Replying to Sebastian Huber:

I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread.

I don't know if this was intended to respond to my concern with custom stack allocators or not. In the systems I know have used this, the memory is not available (mapped dynamically) or known statically (RTEMS runs in virtual address space).

How does this work with custom stack allocators?

[Sebastian Huber]

Replying to Joel Sherrill:

Replying to Sebastian Huber:

I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread.

I don't know if this was intended to respond to my concern with custom stack allocators or not. In the systems I know have used this, the memory is not available (mapped dynamically) or known statically (RTEMS runs in virtual address space).

How does this work with custom stack allocators?

The availability of statically initialized threads doesn't mean that everyone has to use them. They are optional. I also have no intention to remove the custom stack allocator. What changes is that the memory area allocated for the stack is used also to contain the thread-local storage and the FP context. These memory areas are private to a thread and non-executable. I really don't know what a potential problem could be with a custom allocator.

I plan to statically initialize the stacks for the idle threads and the MPCI receive server thread. They will reside in special linker sections so that a BSP or application can control the placement in memory.

[Sebastian Huber <sebastian.huber@…>]

In bf39a9e/rtems:

score: Remove superfluous FP types/defines

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In a0211fc9/rtems:

score: Simplify thread stack allocation

Remove superfluous Thread_Control::Start::stack member.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 0bde56b/rtems:

score: Simplify thread stack free

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 0e1ac917/rtems:

score: Remove _Stack_Ensure_minimum() call

This call is superfluous since _Thread_Initialize() will do this also.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In fc398fd/rtems:

score: Simplify FP context allocation

Use the stack area to allocate the FP context. This considerably
simplifies the application configuration since the task count no longer
influences the configured work space size. With this change the stack
space size is overestimated since an FP context for each thread is
accounted. Memory constraint applications can use the stack size for
fine tuning.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In f4dbf37d/rtems:

score: Simplify TLS area allocation

Use the stack area to allocate the TLS area.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 00c7ad4/rtems:

score: Split stack allocator configuration

This allows the linker garbage collection to perform its work.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In a08dcb2/rtems:

score: Add Thread_Configuration

Add the Thread_Configuration structure to reduce the parameter count of
_Thread_Initialize(). This makes it easier to add more parameters in
the future. It simplifies the code generation since most architectures
do not have that many registers available for function parameters.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 4c9deb6c/rtems:

score: Add _Stack_Extend_size()

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 01d5944/rtems:

score: Move thread stack allocation

Move thread stack allocation to caller side of _Thread_Initialize().

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 32991495/rtems:

score: Statically allocate idle/MPCI stacks

Place idle and MPCI stacks into extra linker sections. This can be
optionally used by applications to control the placement of the stacks.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 6f3bc0e/rtems:

score: Add _Objects_Free_objects_block()

This is a preparation to allow a customization of the objects
information extend.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 2485156/rtems:

score: Split up objects allocation

Split up the different objects allocation methods into separate
functions. This helps to avoid a dependency on the workspace in case no
objects or a static set of objects is configured.

Change license to BSD-2-Clause according to file histories.

Update #3053.
Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 6135747/rtems:

score: Split up objects free

Split up the different objects free methods into separate functions.
This helps to avoid a dependency on the workspace in case no objects or
a static set of objects is configured.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 8e118f22/rtems:

score: Inline _Objects_Namespace_remove_u32()

This function is simple enough to be inlined.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 36e59b2/rtems:

score: _Objects_Extend_information()

Return block index in _Objects_Extend_information(). This allows to
customize the objects information extend.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 8ff1af1/rtems:

score: Add _Freechain_Is_empty()

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 4eab96b/rtems:

score: Add _Freechain_Pop()

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 8a43adb/rtems:

score: Add _Freechain_Extend()

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In dd9e501/rtems:

score: Add _Objects_Activate_unlimited()

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In fc32904/rtems:

score: Add _Objects_Allocate_with_extend()

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In d252e20a/rtems:

score: Simplify _Thread_Initialize()

Allocate new thread queue heads during objects information extend. This
removes an error case and the last dependency on the workspace in
_Thread_Initialize().

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In ed15643/rtems-tools:

linkers: Update due to API changes

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 01c97e64/rtems:

score: Fix label defined but not used warning

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In c6c06ae/rtems-docs:

c-user: Document task memory

Close #3835.

[Sebastian Huber <sebastian.huber@…>]

In 15bba4ae/rtems:

score: Move Thread_Control::Registers member

Place this member placed directly after the end of the common block so that
the structure offsets are as small as possible. This helps on instruction
set architectures with a very limited range for intermediate values. For
example, see the aeabi_read_tp() implementation for ARM Thumb-1.

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 4c89fbcd/rtems:

score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

Update #3835.

[Sebastian Huber <sebastian.huber@…>]

In 45ee958/rtems:

config: Add CONFIGURE_IDLE_TASK_STORAGE_SIZE

By default, allocate the IDLE task storage areas from the RTEMS Workspace.
This avoids having to estimate the thread-local storage size in the default
configuration.

Add the application configuration option CONFIGURE_IDLE_TASK_STORAGE_SIZE to
request a static allocation of the task storage area for IDLE tasks.

Update #3835.
Update #4524.

[Sebastian Huber <sebastian.huber@…>]

In 64fbeaa/rtems:

score: INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL

Ensure that the IDLE storage allocator did allocate a suffiently large area.

Update #3835.
Update #4524.

[Sebastian Huber <sebastian.huber@…>]

In 8f6dd3c/rtems:

arm: Fix Armv7-M TLS support

Set the thread ID register in the CPU context.

Update #3835.
Close #4753.