[release/9.0-staging] Fix assembly labels on MacOS X64 to be LOCAL_LABEL#129535
Open
davidwrighton wants to merge 1 commit into
Open
[release/9.0-staging] Fix assembly labels on MacOS X64 to be LOCAL_LABEL#129535davidwrighton wants to merge 1 commit into
davidwrighton wants to merge 1 commit into
Conversation
Contributor
|
Tagging subscribers to this area: @agocke |
Contributor
There was a problem hiding this comment.
Pull request overview
Backport to release/9.0 of the fix that ensures internal assembly labels in CoreCLR AMD64 Unix .S files are emitted as local symbols on macOS x64, preventing the linker from splitting (“carving up”) functions in a way that can lead to incorrect runtime behavior.
Changes:
- Updated internal labels and branch targets in
ResolveWorkerChainLookupAsmStubto useLOCAL_LABEL(...). - Updated internal labels and branch targets in
ClrRestoreNonvolatileContextWorkerto useLOCAL_LABEL(...).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/coreclr/vm/amd64/virtualcallstubamd64.S | Converts internal loop/exit labels and jumps to LOCAL_LABEL(...) so macOS x64 treats them as local symbols. |
| src/coreclr/vm/amd64/Context.S | Converts internal control-flow labels and jumps to LOCAL_LABEL(...) for correct local symbol emission on macOS x64. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Not doing this leads to the functions being carved up by the linker, which leads to incorrect behavior. (cherry picked from commit e09733c)
davidwrighton
force-pushed
the
backport/129531-net9
branch
from
f28d856 to
9186de9
Compare
davidwrighton
changed the title
Open
3 tasks
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.
Backport of #129531 to release/9.0-staging.
/cc @davidwrighton
Customer Impact
Without this fix, macOS x64 assembly labels can be emitted as ordinary symbols instead of local labels. That can let the linker carve up functions incorrectly, leading to incorrect runtime behavior.
Regression
No known recent regression; this fixes existing assembly label authoring for macOS x64.
Testing
This backport changes
src/coreclr/vm/amd64/Context.Sandsrc/coreclr/vm/amd64/virtualcallstubamd64.S. No new test was added because this is an assembly-label/linker-behavior fix. The source PR and this backport PR rely on CI coverage for the affected release branch.Risk
Low. The change is limited to converting internal assembly labels and branches to LOCAL_LABEL(...) in macOS x64 CoreCLR assembly code, preserving control flow while avoiding externally visible labels.
IMPORTANT: If this backport is for a servicing release, please verify that:
elease/X.0-staging, not
elease/X.0.
Package authoring no longer needed in .NET 9
IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.
Note
This PR description was generated by GitHub Copilot.