Skip to content

Conversation

kateinoigakukun
Copy link
Member

Explanation: Fix memory corruption on WebAssembly by properly reserving low-function addresses
Original PRs: #1987
Risk: Low, this only removes a spurious error for library evolution.
Testing: Ensured at desk that the minimum problematic code won't perform bad memory access with ASan instrumentation
Reviewers: TBD

WebAssembly does not have a reserved address space by default, so we
need to explicitly reserve low addresses for extra inhabitants for
enum types with pointer payloads. swiftlang/swift#39300
added `--global-base` to reserve low data addresses, but we also need
to reserve low function addresses with `--table-base` for function
pointers because WebAssembly uses a separate address space for function
pointers.
@kateinoigakukun kateinoigakukun requested a review from a team as a code owner September 15, 2025 07:15
Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thank you!

@@ -160,8 +160,11 @@ extension WebAssemblyToolchain {
// The value of lowest valid address, called "global base", must be always
// synchronized with `SWIFT_ABI_WASM32_LEAST_VALID_POINTER` defined in
// apple/swift's runtime library.
let SWIFT_ABI_WASM32_LEAST_VALID_POINTER = 4096
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't need to be this PR specifically, but should we export this value as part of the target info that the frontend prints? That way, we don't need to have the hardcoded value duplicated across code bases.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like a good idea, let me make a follow up change on the main branch!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thank you! I don't think we need to cherry-pick the change to release/6.2 or hold up this PR for it, but it would be excellent future-proofing and will help with other platforms where we might need to propagate this information.

@kateinoigakukun
Copy link
Member Author

@swift-ci test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants