LibELF+LibC: Support loading shared objects with dynamic thread-local storage #19809
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
github-actions
bot
added
👀 pr-needs-review
BertalanD
commented
Jul 5, 2023
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! |
This comment was marked as outdated.
This comment was marked as outdated.
BertalanD
force-pushed
the
global-dynamic
branch
2 times, most recently
from
3cba3d6 to
727d57b
Compare
github-actions
bot
added
the
👀 pr-needs-review
timschumi
previously requested changes
Aug 16, 2023
BertalanD
force-pushed
the
global-dynamic
branch
from
727d57b to
9fe73a0
Compare
ADKaster
reviewed
Aug 17, 2023
These should cover all relocation types we can possibly see in an x86_64 or AArch64 final linked ELF image.
LibC is always guaranteed to be loaded at program start, so its thread-local variables live in the static TLS block. This permits us to use the more optimal initial-exec TLS access model.
It's the pointer that should be volatile, not the pointed-to object.
This is a prerequisite for upstreaming our LLVM patches, as our current hack forcing `-ftls-model=initial-exec` in the Clang driver is not acceptable upstream. Currently, our kernel-managed TLS implementation limits us to only having a single block of storage for all thread-local variables that's initialized at load time. This PR merely implements the dynamic TLS interface (`__tls_get_addr` and TLSDESC) on top of our static TLS infrastructure. The current model's limitations still stand: - a single static TLS block is reserved at load time, `dlopen()`-ing shared libraries that define thread-local variables might cause us to run out of space. - the initial TLS image is not changeable post-load, so `dlopen()`-ing libraries with non-zero-initialized TLS variables is not supported. The way we repurpose `ti_module` to mean "offset within static TLS block" instead of "module index" is not ABI-compliant.
The setup is a bit peculiar: both the definition and the use site of these TLS variables have to be in a shared library, otherwise the linker might relax the global-dynamic access mode to something that doesn't require a `__tls_get_addr` call.
BertalanD
force-pushed
the
global-dynamic
branch
from
9fe73a0 to
e84f44d
Compare
gmta
approved these changes
Aug 18, 2023
github-actions
bot
removed
the
👀 pr-needs-review
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.
This is a prerequisite for upstreaming our LLVM patches, which currently need to hackily force the
initial-execTLS model in the Clang driver.Currently, our kernel-managed TLS implementation limits us to only having a single block of storage for all thread-local variables that's initialized at load time. Changing that is outside the scope of this PR, but is in my plans, and there have already been design discussions in
#clang-toolchain. This PR merely implements the dynamic TLS interface (__tls_get_addrand TLSDESC) on top of our static TLS infrastructure. The limitation aboutdlopen()ed shared objects with a non-zero-initialized TLS image and having to fit in the static TLS block still stands.