Emit thunk function for specific ABI on WebAssembly. #6

kateinoigakukun · 2019-10-19T01:32:52Z

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 · 2019-10-19T03:48:16Z

Wow! This is amazing! Thank you so much!

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

kateinoigakukun · 2019-10-19T06:18:27Z

@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 · 2019-10-24T06:29:26Z

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

MaxDesiatov · 2019-10-24T07:33:48Z

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 · 2019-10-25T13:29:58Z

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

kateinoigakukun · 2019-11-10T13:26:27Z

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

lib/SIL/TypeLowering.cpp

MaxDesiatov · 2019-11-12T16:44:08Z

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 · 2019-11-12T20:08:27Z

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 · 2019-11-12T21:29:08Z

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 · 2019-11-12T22:51:13Z

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 · 2019-11-13T20:54:10Z

@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 · 2019-11-14T00:37:59Z

@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 · 2019-11-14T16:17:20Z

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.

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 · 2019-12-14T13:06:28Z

Seems legit, let's get it merged 🙌

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! 🎉

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 · 2019-12-31T01:44:09Z

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

HELP OPEN THE FLOOD GATES

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! 🎉

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 } ```

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! 🎉

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 } ```

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.

kateinoigakukun force-pushed the katei/emit-thunk-for-throw-variant branch from ff96f45 to c4645e3 Compare October 20, 2019 00:17

MaxDesiatov force-pushed the swiftwasm branch from e244560 to 2c73d6c Compare October 22, 2019 15:50

kateinoigakukun force-pushed the katei/emit-thunk-for-throw-variant branch from c4645e3 to 6fd3e31 Compare October 24, 2019 06:27

MaxDesiatov reviewed Nov 10, 2019

View reviewed changes

lib/SIL/TypeLowering.cpp Outdated Show resolved Hide resolved

MaxDesiatov force-pushed the swiftwasm branch from f2bdbfe to 42c6603 Compare November 14, 2019 16:12

Emit thunk function for specific ABI on WebAssembly.

3070daf

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 force-pushed the katei/emit-thunk-for-throw-variant branch from 99a81ce to 3070daf Compare November 15, 2019 14:23

kateinoigakukun mentioned this pull request Dec 14, 2019

[WASM] Link start/stop symbol weakly #21

Merged

MaxDesiatov approved these changes Dec 14, 2019

View reviewed changes

MaxDesiatov merged commit 3e4e71e into swiftwasm:swiftwasm Dec 14, 2019

kateinoigakukun mentioned this pull request Dec 14, 2019

Metadata doesn't work on runtime #20

Closed

kateinoigakukun mentioned this pull request Dec 24, 2019

Fix indirect call type mismatch #30

Closed

kateinoigakukun mentioned this pull request Apr 16, 2020

Revert thunk emission code completely #686

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Emit thunk function for specific ABI on WebAssembly. #6

Emit thunk function for specific ABI on WebAssembly. #6

kateinoigakukun commented Oct 19, 2019

zhuowei commented Oct 19, 2019

kateinoigakukun commented Oct 19, 2019 •

edited

Loading

kateinoigakukun commented Oct 24, 2019 •

edited

Loading

MaxDesiatov commented Oct 24, 2019

kateinoigakukun commented Oct 25, 2019

kateinoigakukun commented Nov 10, 2019

MaxDesiatov commented Nov 12, 2019

MaxDesiatov commented Nov 12, 2019

MaxDesiatov commented Nov 12, 2019 •

edited

Loading

kateinoigakukun commented Nov 12, 2019 •

edited

Loading

MaxDesiatov commented Nov 13, 2019

kateinoigakukun commented Nov 14, 2019

MaxDesiatov commented Nov 14, 2019 •

edited

Loading

MaxDesiatov commented Dec 14, 2019

hggz commented Dec 31, 2019

Emit thunk function for specific ABI on WebAssembly. #6

Emit thunk function for specific ABI on WebAssembly. #6

Conversation

kateinoigakukun commented Oct 19, 2019

zhuowei commented Oct 19, 2019

kateinoigakukun commented Oct 19, 2019 • edited Loading

kateinoigakukun commented Oct 24, 2019 • edited Loading

MaxDesiatov commented Oct 24, 2019

kateinoigakukun commented Oct 25, 2019

kateinoigakukun commented Nov 10, 2019

MaxDesiatov commented Nov 12, 2019

MaxDesiatov commented Nov 12, 2019

MaxDesiatov commented Nov 12, 2019 • edited Loading

kateinoigakukun commented Nov 12, 2019 • edited Loading

MaxDesiatov commented Nov 13, 2019

kateinoigakukun commented Nov 14, 2019

MaxDesiatov commented Nov 14, 2019 • edited Loading

MaxDesiatov commented Dec 14, 2019

hggz commented Dec 31, 2019

kateinoigakukun commented Oct 19, 2019 •

edited

Loading

kateinoigakukun commented Oct 24, 2019 •

edited

Loading

MaxDesiatov commented Nov 12, 2019 •

edited

Loading

kateinoigakukun commented Nov 12, 2019 •

edited

Loading

MaxDesiatov commented Nov 14, 2019 •

edited

Loading