Add support for ELF thread-local storage #419
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Handling thread-local storage in the binary format significantly simplifies its implementation by removing the need for dynamic allocation of keys and memory. The ELF format, used as a compiler target for SGX, does feature the required extensions1.
Because SGX binaries are statically linked and do not support dynamic loading of libraries, only the local-exec model needs to be supported, which has the added benefit of not needing any additional relocations. In this model, the
fssegment is used as a thread pointer, pointing to a thread control block whose first entry contains the thread pointer itself (thereby allowing simpler address computations). The TLS data is placed in front of the TCB and is accessed by subtracting fixed offsets (obtained at link-time) from the thread pointer.Because SGX supports only a fixed number of threads, this TLS area can be statically allocated for each thread, avoiding memory allocation failures. Also, since the
fssegment was previously unused, the tool can remain backwards-compatible by setting thegssegment to the address of the old TCB block (located 8 bytes above the thread pointer). New software should probably access the TCB via thefssegment, however, so that thegssegment can be used for other purposes in the future.Since this PR implements new features, I assume the toolchain version will need to be bumped, but I am unsure of the process for that.
Footnotes
https://uclibc.org/docs/tls.pdf ↩