[WIP]: Regression test validating usage of static TLS resolver on Linux ARM64. - #131995
Draft
lateralusX wants to merge 1 commit into
Draft
[WIP]: Regression test validating usage of static TLS resolver on Linux ARM64.#131995lateralusX wants to merge 1 commit into
lateralusX wants to merge 1 commit into
Conversation
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @agocke |
Contributor
There was a problem hiding this comment.
Pull request overview
Adds coverage to ensure CoreCLR uses the static TLS resolver by default on Linux ARM64 (and retains existing coverage for the forced-dynamic resolver scenario), via a new config-driven assertion in the CoreCLR TLS optimization check and an extended test that exercises a managed [ThreadStatic] access in a child process.
Changes:
- Extend
TestTLSWithLoadedDllsto spawn a Linux/ARM64 child process that accesses a managed thread-static field and asserts the static TLS resolver is available. - Add a new CoreCLR config knob (
AssertStaticTlsResolver) that asserts when the static TLS resolver path is not available (checked/debug builds). - Refactor the test’s child-process launch logic to allow selecting which assertion env var to set.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/tests/JIT/Directed/tls/TestTLSWithLoadedDlls.cs | Adds a [ThreadStatic] access path and a Linux/ARM64 child-process run that asserts the static TLS resolver; factors process launching into a helper. |
| src/coreclr/vm/threadstatics.cpp | Adds a checked/debug assertion gate to verify the static TLS resolver is available when requested via config. |
| src/coreclr/inc/clrconfigvalues.h | Introduces EXTERNAL_AssertStaticTlsResolver configuration entry. |
Comment on lines
+113
to
116
| private static int RunChildProcess(string arguments, string assertionVariable) | ||
| { | ||
| Process process = new Process(); | ||
| process.StartInfo.FileName = GetCorerunPath(); |
This file contains hidden or 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.
WIP.
Summary
Adds a regression test that verifies CoreCLR receives a static TLS resolver under normal Linux ARM64 startup conditions.
Motivation
#131954 exposed a runtime-wide performance cliff when
libcoreclr.soexceeded glibc's optional static TLS capacity. The loader silently switched CoreCLR from_dl_tlsdesc_returnto_dl_tlsdesc_dynamic, significantly slowing common TLS accesses.The existing
TestTLSWithLoadedDllstest validates behavior after forcing the dynamic resolver, but does not verify that normal startup continues to use the static resolver.Changes
DOTNET_AssertStaticTlsResolver, the inverse of the existing dynamic-resolver assertion.TestTLSWithLoadedDllswith a Linux ARM64 child process that:WIP validation plan
This PR is intentionally based on
main, before the proposed fix for #131954 (#131991) to confirm that the regression test fails against the affected runtime.Once confirmed, it will be rebased onto the TLS deduplication fix (#131991) to verify that the test passes.