TLS support for libdl

[Chris Johns]

TLS support for libdl

Contents

1. TLS support for libdl
   1. Mentors
   2. Status
2. Introduction
   1. TLS Varables
   2. Run-time Loaded TLS Variables
3. Project
   1. Goal
   2. Prerequisite
   3. Difficulty
   4. Resources
4. Tasks
5. Acknowledgements
6. Miscellaneous Sections
7. References

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