Dynamic linker needs full TLS support

[Jiri Svoboda]

Currently the dynamic linker can only handle thread-local variables that are static, because it does cannot resolve module numbers in the TLS runtime functions.

Also, thread-local variables can currently only be in one runtime module (the C library) because of the way global symbols are used to measure tdata and tbss sections.

[Jiri Svoboda]

There is a special TLS program header that describes the thread-local data section. For this to work tbss should follow tdata (there can be alignment padding between them). From the filesize and memsize of this segment the dynamic loader can derive the beginning and size of tdata and tbss for each module.

[Jiri Svoboda]

I think the amount of work that needs to be done for this ticket is very small, on the other hand this requires expert knowledge of ELF/HelenOS dynamic linking, so it does not seem very suitable as a GSoC assignment.

[Jiri Svoboda]

There needs to be a program header of type PT_TLS covering the TLS initialization image (.tdata followed by .tbss) (see ELF Handling for Thread-Local Storage 2005 page 4). This is used by the run-time linker.

• add PHDR of type PT_TLS to linker script
• RTLD to read TLS initialization image header
• RTLD to load TLS initialization image

[Jiri Svoboda]

Ad above, to mimic Linux .tdata and .tbss can be put in a separate PT_LOAD segment and at the same time in the PT_TLS segment (thus ensuring they are loaded automatically).

• rtld needs to assign a number/ID to each loaded module
• __make_tls(), __free_tls() and friends need to construct TLS, dtv for all loaded modules
• modify arch's __tls_get_addr() to take module number into account and use dtv
• dlopen() needs to add the new module's TLS to all existing threads

[Jiri Svoboda]

Merged in mainline,2510.