[Runtime][IRGen] Trap C++ exceptions on *throw*, not catch. #71056
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
|
We might need to do something to make sure that the Linux build still works for people while we're landing this — building with host tools is probably going to cause a problem because of the extra API that the compiler is using. |
|
@swift-ci Please test |
mikeash
approved these changes
Jan 22, 2024
|
Someday, can we emit this unconditionally to prevent people trying to throw through Swift frames and catch them on the other side? |
al45tair
requested review from
a team,
zoecarver and
egorzhdan
as code owners
|
@swift-ci Please test |
Azoy
reviewed
Jan 23, 2024
al45tair
force-pushed
the
eng/PR-120952971
branch
from
24a2031 to
3e2b018
Compare
|
There's also an issue in that gating on availability means the test needs to pass the availability flags. I'm going to fix the availability situation on Linux and then come back to this PR. |
al45tair
force-pushed
the
eng/PR-120952971
branch
from
3e2b018 to
c7e74d7
Compare
|
@swift-ci Please smoke test |
al45tair
force-pushed
the
eng/PR-120952971
branch
from
c7e74d7 to
ec01501
Compare
|
@swift-ci Please smoke test |
al45tair
force-pushed
the
eng/PR-120952971
branch
3 times, most recently
from
89ee1f5 to
16f27d6
Compare
|
@swift-ci Please smoke test |
mikeash
approved these changes
Feb 5, 2024
The previous approach was effectively to catch the exception and then run a trap instruction. That has the unfortunate feature that we end up with a crash at the catch site, not at the throw site, which leaves us with very little information about which exception was thrown or where from. (Strictly we do have the exception pointer and could obtain exception information, but it still won't tell us what threw it.) Instead of that, set a personality function for Swift functions that call potentially throwing code, and have that personality function trap the exception during phase 1 (i.e. *before* the original stack has been unwound). rdar://120952971
The exception handling tests should check for the new personality, and the ABI check needs to know about the new entry point in the runtime. rdar://120952971
The other new runtime functions appear to have a leading underscore. It makes sense in this case because we don't expect anything to call this directly (other than the unwinder). rdar://120952971
We need to only generate references to `_swift_exceptionPersonality` if we're building for a new enough runtime. The previous code was good on Darwin, but would have resulted in build problems on Linux. rdar://120952971
al45tair
force-pushed
the
eng/PR-120952971
branch
from
16f27d6 to
76f2389
Compare
|
Rebased. |
|
@swift-ci Please smoke test |
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.
The previous approach was effectively to catch the exception and then run a trap instruction. That has the unfortunate feature that we end up with a crash at the catch site, not at the throw site, which leaves us with very little information about which exception was thrown or where from.
(Strictly we do have the exception pointer and could obtain exception information, but it still won't tell us what threw it.)
Instead of that, set a personality function for Swift functions that call potentially throwing code, and have that personality function trap the exception during phase 1 (i.e. before the original stack has been unwound).
rdar://120952971