[runtime] Backwards-deployment support for class_getImageName #18060
Conversation
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
|
@swift-ci Please test |
|
Build failed |
jrose-apple
force-pushed
the
and-you-get-a-class_getImageName
branch
from
c4f6f31 to
271cc0d
Compare
|
Full macOS tests here. I just failed to account for the new files getting compiled on Linux too. @swift-ci Please smoke test |
Follow-up to 3ed3774. On Apple OSs that don't have the new Objective-C runtime function 'objc_setHook_getImageName', override the system definition of 'class_getImageName' by literally rewriting symbol tables at run time. Yes, you read that correctly. The low-level part of this patch was written by Greg Parker, then simplified and tweaked by me to fit the Swift coding style. Don't try this at home; it comes with all sorts of caveats and won't actually work on this year's iOS. (Fortunately we don't need it there, because that will have the new ObjC entry point.) The rest of the patch is pretty straightforward: the replacement implementation calls the code that supports Swift objects (the same code we use on newer OSs), which then chains back to the original system implementation of class_getImageName. May we never have to touch this again. rdar://problem/41535552
Reverts the effects of df974b2, but keeps the refactoring and nicer tests.
jrose-apple
force-pushed
the
and-you-get-a-class_getImageName
branch
from
271cc0d to
e9f71fd
Compare
|
@swift-ci Please smoke test |
jrose-apple
added a commit
to jrose-apple/swift
that referenced
this pull request
Jul 19, 2018
…ss_getImageName [runtime] Backwards-deployment support for class_getImageName https://bugs.swift.org/browse/SR-1917 rdar://problem/41535552 (cherry picked from commit 6f42fcc)
jrose-apple
added a commit
that referenced
this pull request
Jul 19, 2018
Merge pull request #18060 from jrose-apple/and-you-get-a-class_getImageName https://bugs.swift.org/browse/SR-1917 rdar://problem/41535552 (cherry picked from commit 6f42fcc)
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.
Follow-up to #17910. On Apple OSs that don't have the new Objective-C runtime function
objc_setHook_getImageName, override the system definition ofclass_getImageNameby literally rewriting symbol tables at run time.Yes, you read that correctly.
The low-level part of this patch was written by @gparker42, then simplified and tweaked by me to fit the Swift coding style. Don't try this at home; it comes with all sorts of caveats and won't actually work on this year's iOS. (Fortunately we don't need it there, because that will have the new ObjC entry point.)
The rest of the patch is pretty straightforward: the replacement implementation calls the code that supports Swift objects (the same code we use on newer OSs), which then chains back to the original system implementation of
class_getImageName. May we never have to touch this again.SR-1917 / rdar://problem/41535552