[RTEMS Project] #3712: TLS support for libdl
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 ==
== 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 =
Ticket URL: <http://devel.rtems.org/ticket/3712>
RTEMS Project <http://www.rtems.org/>
More information about the bugs