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

Emit thunk function for specific ABI on WebAssembly. #6

Conversation

kateinoigakukun
Copy link
Member

Changed to make thunk to convert thin-to-thick and non-throws-to-throws.
We needs it on WebAssembly host because WASM checks number of arguments strictly for indirect function call.

This patch allows you to run the Swift code below.

func f(_ a: (Int) -> Void) {
    g(a)
}

func g(_ b: (Int) throws -> Void) {
    try! b(1)
}

f { _ in }

@zhuowei
Copy link

zhuowei commented Oct 19, 2019

Wow! This is amazing! Thank you so much!

I haven't tested this: does this also handle the optional protocol witness parameters?

@kateinoigakukun
Copy link
Member Author

kateinoigakukun commented Oct 19, 2019

@zhuowei Thanks 😊

does this also handle the optional protocol witness parameters?

I didn't care about that and I can't figure out how the problem happens. Could you give me an example for the case?

@kateinoigakukun
Copy link
Member Author

kateinoigakukun commented Oct 24, 2019

I tracked upstream branch 👍 (BTW rebasing main branch swiftwasm causes many conflicts 😅

@MaxDesiatov
Copy link

I'm sorry about that, I thought about using merge commits instead of rebase, but downside is that the main swift repository uses merge commits too. Adding our own would potentially make commit history quite unreadable. Please let us know if you think there's a better solution 🙏

@kateinoigakukun
Copy link
Member Author

@MaxDesiatov Thanks for maintaining this downstream repo 👍
I have no idea to solve this problem. All we can do is "moving fast". 😅

@kateinoigakukun
Copy link
Member Author

@zhuowei Sorry for pinging you. Can I merge this patch?

lib/SIL/TypeLowering.cpp Outdated Show resolved Hide resolved
@MaxDesiatov
Copy link

When building an SDK with this branch using swiftwasm-package-sdk and using the packaged swiftwasm script I get this error:

~/swiftwasm-package-sdk/output/swiftwasm-sdk$ ./swiftwasm example/hello.swift out.wasm
wasm-ld: error: ./opt/swiftwasm-sdk/lib/swift_static/wasm/wasm32/swiftrt.o: Bad section type

I currently don't have any knowledge of what this file is expected to contain, a basic check shows this:

~/swiftwasm-package-sdk/output/swiftwasm-sdk$ file opt/swiftwasm-sdk/lib/swift_static/wasm/wasm32/swiftrt.o 
opt/swiftwasm-sdk/lib/swift_static/wasm/wasm32/swiftrt.o: WebAssembly (wasm) binary module version 0x1 (MVP)

I've built everything using this branch with swiftwasm branch merged in and its build-linux.sh script, then cloned swiftwasm-package-sdk, put the compiled prebuilts and used ./buildPackages.sh to get the package.

@kateinoigakukun hope you could provide some pointers to where things could have gone wrong?

@MaxDesiatov
Copy link

My current hunch is that this broke after merging #11, maybe a simple update to the swiftwasm script could fix this? Should "$sdk/extra_objs/swift_start.o" and "$sdk/extra_objs/swift_end.o" be removed from the list of linker arguments?

@MaxDesiatov
Copy link

MaxDesiatov commented Nov 12, 2019

Just got the artifacts uploaded for swiftwasm-sdk and updated links for those in swiftwasm-package-sdk, now this is stably reproducible this way (these commands are for macOS, but I got the same message on Linux as described a few comments above):

git clone https://github.com/swiftwasm/swiftwasm-package-sdk.git
cd swiftwasm-package-sdk
./downloadPrebuilts.sh
./buildPackages.sh
cd output
tar xf swiftwasm-sdk-macos.tar.xz
cd swiftwasm-sdk
./swiftwasm example/hello.swift hello.wasm

yields

wasm-ld: error: ./opt/swiftwasm-sdk/lib/swift_static/wasm/wasm32/swiftrt.o: Bad section type

It's not that the isue is caused by this PR, but it seems to be caused by #11 or some other changes since the last binary packages were built for swiftwasm-package-sdk, and it currently prevents me from testing this PR.

@kateinoigakukun
Copy link
Member Author

kateinoigakukun commented Nov 12, 2019

When building an SDK with this branch using swiftwasm-package-sdk and using the packaged swiftwasm script I get this error:

@MaxDesiatov I think Bad section type error is due to your old wasm-ld. (I faced same error after rebased upstream apple/swift.)
Please use wasm-ld 9.0.0 or above.

$ wasm-ld --version
LLD 9.0.0 (https://github.com/llvm/llvm-project 0399d5a9682b3cef71c653373e38890c63c4c365)

If you can't resolve by updating wasm-ld, please try to validate the object file using wasm-validate

My current hunch is that this broke after merging #11, maybe a simple update to the swiftwasm script could fix this? Should "$sdk/extra_objs/swift_start.o" and "$sdk/extra_objs/swift_end.o" be removed from the list of linker arguments?

Yeah, need to remove swift_start.o and swift_end.o. My linker command arguments are here https://github.com/kateinoigakukun/swiftwasm-scripts/blob/ee1c86feacdc97e0d1864fe419799542d398c75a/build.sh#L83-L97

@MaxDesiatov
Copy link

@kateinoigakukun thanks for the tip!

I've managed to get fresh wasm-ld and the bad section error went away, but now I stumble upon these new errors both with build.sh script from your swiftwasm-scripts project and swiftwasm script from our swiftwasm-package-sdk:

wasm-ld: error: ./opt/swiftwasm-sdk/lib/swift_static/wasm/libswiftCore.a: archive has no index; run ranlib to add one
wasm-ld: error: ./opt/swiftwasm-sdk/lib/swift_static/wasm/libswiftImageInspectionShared.a: archive has no index; run ranlib to add one

@kateinoigakukun
Copy link
Member Author

@MaxDesiatov Ah, I faced same error too archive has no index; run ranlib to add one. You may be using ranlib and ar built in Xcode. Please ensure that CMAKE_AR and CMAKE_RANLIB points llvm-ar and lllvm-ranlib in CMakeCache.txt

@MaxDesiatov
Copy link

MaxDesiatov commented Nov 14, 2019

This PR will need to be rebased on top of swiftwasm and force-pushed at some point. I had to rebase swiftwasm on top of master in an attempt to resolve compatibility issues with the latest llvm-project, which in turn was apparently needed for latest wasi-sdk.

Changed to make thunk to convert thin-to-thick and non-throws-to-throws,
We needs it on WebAssembly host because WASM checks number of
arguments strictly for indirect function call.
@kateinoigakukun kateinoigakukun force-pushed the katei/emit-thunk-for-throw-variant branch from 99a81ce to 3070daf Compare November 15, 2019 14:23
MaxDesiatov pushed a commit that referenced this pull request Dec 14, 2019
This PR fixed my runtime implementation in SwiftRT.
I've inserted dummy `char` data in each metadata sections to ensure that all start/stop symbols are generated in #11. But of cource this dummy data can be inserted anywhere in the section, so metadata sections were broken by this 1 byte.

I changed to link these start/stop symbols weakly. Non-generated start/stop variables get to be uninitialized. So `stop-start` results 0 length, and runtime library can avoid to load empty section.

After this and #6 are merged, `print("Hello")` will work again! 🎉
@MaxDesiatov
Copy link

Seems legit, let's get it merged 🙌

@MaxDesiatov MaxDesiatov merged commit 3e4e71e into swiftwasm:swiftwasm Dec 14, 2019
kateinoigakukun added a commit to kateinoigakukun/swift that referenced this pull request Dec 14, 2019
This PR fixed my runtime implementation in SwiftRT.
I've inserted dummy `char` data in each metadata sections to ensure that all start/stop symbols are generated in swiftwasm#11. But of cource this dummy data can be inserted anywhere in the section, so metadata sections were broken by this 1 byte.

I changed to link these start/stop symbols weakly. Non-generated start/stop variables get to be uninitialized. So `stop-start` results 0 length, and runtime library can avoid to load empty section.

After this and swiftwasm#6 are merged, `print("Hello")` will work again! 🎉
kateinoigakukun added a commit that referenced this pull request Dec 15, 2019
Changed to make thunk to convert thin-to-thick and non-throws-to-throws. 
We needs it on WebAssembly host because WASM checks number of arguments strictly for indirect function call.

This patch allows you to run the Swift code below.

```swift
func f(_ a: (Int) -> Void) {
    g(a)
}

func g(_ b: (Int) throws -> Void) {
    try! b(1)
}

f { _ in }
```
@hggz
Copy link

hggz commented Dec 31, 2019

https://forums.swift.org/t/reality-vs-reality/31835/24

HELP OPEN THE FLOOD GATES

kateinoigakukun added a commit to kateinoigakukun/swift that referenced this pull request Jan 11, 2020
This PR fixed my runtime implementation in SwiftRT.
I've inserted dummy `char` data in each metadata sections to ensure that all start/stop symbols are generated in swiftwasm#11. But of cource this dummy data can be inserted anywhere in the section, so metadata sections were broken by this 1 byte.

I changed to link these start/stop symbols weakly. Non-generated start/stop variables get to be uninitialized. So `stop-start` results 0 length, and runtime library can avoid to load empty section.

After this and swiftwasm#6 are merged, `print("Hello")` will work again! 🎉
kateinoigakukun added a commit that referenced this pull request Jan 11, 2020
Changed to make thunk to convert thin-to-thick and non-throws-to-throws. 
We needs it on WebAssembly host because WASM checks number of arguments strictly for indirect function call.

This patch allows you to run the Swift code below.

```swift
func f(_ a: (Int) -> Void) {
    g(a)
}

func g(_ b: (Int) throws -> Void) {
    try! b(1)
}

f { _ in }
```
kateinoigakukun added a commit to kateinoigakukun/swift that referenced this pull request Jan 24, 2020
This PR fixed my runtime implementation in SwiftRT.
I've inserted dummy `char` data in each metadata sections to ensure that all start/stop symbols are generated in swiftwasm#11. But of cource this dummy data can be inserted anywhere in the section, so metadata sections were broken by this 1 byte.

I changed to link these start/stop symbols weakly. Non-generated start/stop variables get to be uninitialized. So `stop-start` results 0 length, and runtime library can avoid to load empty section.

After this and swiftwasm#6 are merged, `print("Hello")` will work again! 🎉
kateinoigakukun added a commit to kateinoigakukun/swift that referenced this pull request Jan 25, 2020
This PR fixed my runtime implementation in SwiftRT.
I've inserted dummy `char` data in each metadata sections to ensure that all start/stop symbols are generated in swiftwasm#11. But of cource this dummy data can be inserted anywhere in the section, so metadata sections were broken by this 1 byte.

I changed to link these start/stop symbols weakly. Non-generated start/stop variables get to be uninitialized. So `stop-start` results 0 length, and runtime library can avoid to load empty section.

After this and swiftwasm#6 are merged, `print("Hello")` will work again! 🎉
MaxDesiatov pushed a commit that referenced this pull request Jan 29, 2020
Changed to make thunk to convert thin-to-thick and non-throws-to-throws. 
We needs it on WebAssembly host because WASM checks number of arguments strictly for indirect function call.

This patch allows you to run the Swift code below.

```swift
func f(_ a: (Int) -> Void) {
    g(a)
}

func g(_ b: (Int) throws -> Void) {
    try! b(1)
}

f { _ in }
```
pull bot pushed a commit that referenced this pull request Sep 24, 2021
typelayout_based_value_witness.swift failed on iphoneos-arm64e due to an extra
line of IR that gets generated. That meant the swift_release line had '#7'
instead of '#6'. The test shouldn't be checking for '#6' anyways, so removed
that check which causes the test to now pass.
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.

None yet

4 participants