[RTEMS Project] #3712: TLS support for libdl

RTEMS trac trac at rtems.org
Mon Mar 4 03:54:41 UTC 2019

#3712: TLS support for libdl
  Reporter:  Chris Johns  |      Owner:  (none)
      Type:  project      |     Status:  new
  Priority:  normal       |  Milestone:  Indefinite
 Component:  lib/dl       |    Version:
  Severity:  normal       |   Keywords:  SoC,ecosystem,libdl
Blocked By:               |   Blocking:
 = 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

 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

 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-

 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.

 == Resources ==

 * Current RTEMS developers.

 = Tasks =

 The following are the tasks:


 = Acknowledgements =


 = 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

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

More information about the bugs mailing list