Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop renaming main symbol for WASI #3804

Merged
merged 4 commits into from
Oct 18, 2021

Conversation

kateinoigakukun
Copy link
Member

@kateinoigakukun kateinoigakukun commented Oct 13, 2021

Stop renaming main symbol for WASI due to lack of support in the linker

Motivation:

The latest SwiftPM rename main entry point name of executable target to avoid conflicting "main" with test target since swift-tools-version >= 5.5.
The main symbol is renamed to "{{module_name}}_main" and it's renamed again to be "main" when linking the executable target. The former renaming is done by Swift compiler, and the latter is done by linker, so SwiftPM passes some special linker flags for each platform.
But SwiftPM assumed that wasm-ld supports it by returning an empty array instead of nil even though wasm-ld doesn't support it yet.

Modifications:

This patch changed linkerFlagsForRenamingMainFunction to return nil when targeting WASI to indicate it's not supported.

However, for a long-term solution, this renaming feature should be supported on wasm-ld because it's not a limitation of WebAssembly.

See also: swiftwasm/swift#3645
CC: @MaxDesiatov

For a long-term solution, this renaming feature should be supported on
wasm-ld because it's not a limitation of WebAssembly.
@MaxDesiatov
Copy link
Contributor

@swift-ci please smoke test

@abertelrud
Copy link
Contributor

abertelrud commented Oct 13, 2021

Thank you for this fix! I'm actually wondering if it's ever correct for this function to return an empty array. This looks like a logic error from the start. Should it perhaps always return nil if the linker doesn't support it, not just for WASI? This fix is great, but it looks as if on Windows the compiler would still be asked to rename the symbol but the linker wouldn't be asked to name it back.

for other than linux and darwin platforms
@kateinoigakukun
Copy link
Member Author

@swift-ci please smoke test

@tomerd
Copy link
Contributor

tomerd commented Oct 14, 2021

thanks @kateinoigakukun

@abertelrud
Copy link
Contributor

Thanks @kateinoigakukun! Would it make sense to extend one of the unit tests for this (or add a new one)?

The call of checkSupportedFrontendFlags is moved from BuildPlan to test
it in file system independently. The check needs to access temp file,
but the in-memory fs doesn't allow that.
@kateinoigakukun
Copy link
Member Author

@swift-ci please smoke test

@abertelrud
Copy link
Contributor

Thanks for the update, @kateinoigakukun. Having a separate boolean makes sense to me, would be interested in hearing what @neonichu and @tomerd think as well.

@tomerd
Copy link
Contributor

tomerd commented Oct 15, 2021

Having a separate boolean makes sense to me, would be interested in hearing what @neonichu and @tomerd think as well.

same: +1, although the current boolean flag is more of canRenameEntrypointFunctionName than shouldRenameEntrypointFunctionName?

@MaxDesiatov
Copy link
Contributor

@swift-ci please smoke test

Copy link
Contributor

@abertelrud abertelrud left a comment

Choose a reason for hiding this comment

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

Thanks, this looks good to me!

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

Successfully merging this pull request may close these issues.

5 participants