[RTEMS Project] #3712: TLS support for libdl

[RTEMS trac]

#3712: TLS support for libdl
-------------------------------------+--------------------------
 Reporter:  Chris Johns              |       Owner:  Chris Johns
     Type:  project                  |      Status:  closed
 Priority:  normal                   |   Milestone:  Indefinite
Component:  lib/dl                   |     Version:
 Severity:  normal                   |  Resolution:  duplicate
 Keywords:  SoC,kernel,libdl, large  |  Blocked By:
 Blocking:                           |
-------------------------------------+--------------------------
Changes (by Gedare Bloom):

 * status:  assigned => closed
 * resolution:   => duplicate


Old description:

> = TLS support for libdl =
>
> [[PageOutline(1-5, Contents, inline)]]
>
> == Mentors ==
> Chris Johns
>
> == Status ==
>
> = Introduction =
>
> The goal of this project is to support TLS variables in code loaded using
> `libdl`.
>
> RTEMS supports the run-time loading of the executable code using the
> `dlopen` family of calls. The implementation is in `libdl`. Thread Local
> Storage (TLS) is not support. Code containing TLS will not load and so
> cannot be run.
>
> == TLS Varables ==
>
> TLS data is private to each thread. A thread is allocated a block of data
> when it is create to hold the system wide TLS variables. When code
> references a TLS variable it uses an offset from a system defined and
> reserved register to access the memory. With a statically linked
> executable all the TLS variables are known so the space allocated is
> known. Initialized TLS variables need to initialized when a thread is
> created.
>
> TLS has an overhead. The thread specific storage adds to the allocation
> overhead when a thread is created, as well as thread create time as the
> memory needs to be initialized or cleared. It is useful to hold pointer
> to large object and use by RTEMS system level software should be avoided.
>
> TLS needs compiler support to work and this means the ABI the compiler
> implements defines how TLS variables are defined and operate.
>
> == Run-time Loaded TLS Variables ==
>
> Run-time loading TLS variables complicates the how TLS variables are
> implemented in RTEMS and how TLS variables are used. Space needs to be
> reserved in all threads to cater for variables that are loaded at run-
> time.
>
> Space is allocated to TLS variables from the special memory attached to
> each thread as they are loaded until the reserved space is consumed. TLS
> variable symbols are treated differently to other variables loaded at
> run-time. Space allocated to a TLS cannot be used again until the TLS
> symbol that references it is removed from the system by the unloading of
> the executable object file that contains it.
>
> Initialization of new variables in existing threads can happen without
> suspending a thread. A new TLS variable is only available to a running
> thread once the executable object has finished being loaded so the memory
> can be touched while the thread is running. The thread cannot be deleted
> while the initialisation is happening. Threads that start after TLS
> variables have been loaded need to have their TLS memory initialized.
>
> RTEMS cannot afford to suspend threads to dynamically allocate more space
> to TLS variables.
>
> = Project =
>
> The project is to add support to the RTEMS `score` and `libdl` to support
> the loading of executable object files with TLS variables.
>
> == Goal ==
>
> * Update the `score` to allow reserve extra TLS memory
> * Provide an allocator to the memory.
> * Add a TLS symbol table to `libdl`.
> * Add TSL variable tests to the testsuite.
>
> == Prerequisite ==
>
> This is an advanced project with a lot of detail. Parts of the code need
> to be in the `score` and deep in the TCB for threads. Code accuracy and
> clarity is important.
>
> * Advanced knowledge of C.
> * An understanding of ELF and TLS.
> * Ability to read detail documents on file formats and operating
> characteristics such as ABI details for an architecture.
> * Experience with a few RTEMS tier 1 architectures.
>
> == Difficulty ==
> This is a large (350-hour) project of hard difficulty.
>
> == Resources ==
>
> * Current RTEMS developers.
>
> = Tasks =
>
> The following are the tasks:
>
> TDB
>
> = Acknowledgements =
>
> None.
>
> = Miscellaneous Sections =
>
> As the project progresses, you will need to add to the RTEMS Testing
> section of the User manual. This section does not currently exist but it
> should be present even in a skeleton form.
>
> = References =
>
> * None

New description:

 = TLS support for libdl =

 [[PageOutline(1-5, Contents, inline)]]

 == Mentors ==
 Chris Johns

 == Status ==

 = Introduction =

 The goal of this project is to support TLS variables in code loaded using
 `libdl`.

 RTEMS supports the run-time loading of the executable code using the
 `dlopen` family of calls. The implementation is in `libdl`. Thread Local
 Storage (TLS) is not support. Code containing TLS will not load and so
 cannot be run.

 == TLS Varables ==

 TLS data is private to each thread. A thread is allocated a block of data
 when it is create to hold the system wide TLS variables. When code
 references a TLS variable it uses an offset from a system defined and
 reserved register to access the memory. With a statically linked
 executable all the TLS variables are known so the space allocated is
 known. Initialized TLS variables need to initialized when a thread is
 created.

 TLS has an overhead. The thread specific storage adds to the allocation
 overhead when a thread is created, as well as thread create time as the
 memory needs to be initialized or cleared. It is useful to hold pointer to
 large object and use by RTEMS system level software should be avoided.

 TLS needs compiler support to work and this means the ABI the compiler
 implements defines how TLS variables are defined and operate.

 == Run-time Loaded TLS Variables ==

 Run-time loading TLS variables complicates the how TLS variables are
 implemented in RTEMS and how TLS variables are used. Space needs to be
 reserved in all threads to cater for variables that are loaded at run-
 time.

 Space is allocated to TLS variables from the special memory attached to
 each thread as they are loaded until the reserved space is consumed. TLS
 variable symbols are treated differently to other variables loaded at run-
 time. Space allocated to a TLS cannot be used again until the TLS symbol
 that references it is removed from the system by the unloading of the
 executable object file that contains it.

 Initialization of new variables in existing threads can happen without
 suspending a thread. A new TLS variable is only available to a running
 thread once the executable object has finished being loaded so the memory
 can be touched while the thread is running. The thread cannot be deleted
 while the initialisation is happening. Threads that start after TLS
 variables have been loaded need to have their TLS memory initialized.

 RTEMS cannot afford to suspend threads to dynamically allocate more space
 to TLS variables.

 = Project =

 The project is to add support to the RTEMS `score` and `libdl` to support
 the loading of executable object files with TLS variables.

 == Goal ==

 * Update the `score` to allow reserve extra TLS memory
 * Provide an allocator to the memory.
 * Add a TLS symbol table to `libdl`.
 * Add TSL variable tests to the testsuite.

 == Prerequisite ==

 This is an advanced project with a lot of detail. Parts of the code need
 to be in the `score` and deep in the TCB for threads. Code accuracy and
 clarity is important.

 * Advanced knowledge of C.
 * An understanding of ELF and TLS.
 * Ability to read detail documents on file formats and operating
 characteristics such as ABI details for an architecture.
 * Experience with a few RTEMS tier 1 architectures.

 == Difficulty ==
 This is a large (350-hour) project of hard difficulty.

 == Resources ==

 * Current RTEMS developers.

 = Tasks =

 The following are the tasks:

 TDB

 = Acknowledgements =

 None.

 = Miscellaneous Sections =

 As the project progresses, you will need to add to the RTEMS Testing
 section of the User manual. This section does not currently exist but it
 should be present even in a skeleton form.

 = References =

 * None.

--

Comment:

 This is now a tracked blocker defect #4920.

--
Ticket URL: <http://devel.rtems.org/ticket/3712#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project