-
Notifications
You must be signed in to change notification settings - Fork 201
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
New-style command support. #203
Conversation
The core idea of new-style commands is that all function exports are command entrypoints, and they expect to be called on a fresh instance which lives only for the direction of the call. This is a generalization of the existing `_start` convention, which already has the expectation of a fresh instance which lives only for the direction of the call, and is one of the pieces need to enable user-defined command entrypoints which don't take string arguments and don't return an i32 status code. To show how this works in practice, the following patches implement this new behavior in wasm-ld and wasi-libc: - https://reviews.llvm.org/D81689 - WebAssembly/wasi-libc#203
1b6be6b
to
71d07cb
Compare
This currently depends on wasm-ld having https://reviews.llvm.org/D81689 in it. Since we're just now dropping support for LLVM 8.0, we'll need to think more about how to manage compatibility here. |
Should we tag/branch for each major llvm release that we support? |
Branch/tag sounds difficult if these live a long time and we end up having to backport patches to all the branches. I'm thinking about moving the crt1.c in this PR to crt1-command.c, and restoring the previous crt1.c, so that one libc can support both old and new styles -- the compiler driver would be able to pick which one it wants. I'll investigate this in more detail after https://reviews.llvm.org/D81689 lands. |
This adds a new crt1-command.c startup file, which uses [new-style command support]. Instead of calling `__wasm_call_ctors` and `__wasm_call_dtors` directly, this lets wasm-ld automatically call them. This preserves the existing crt1.c, so that the same wasi-libc build can support old-style and new-style commands, for compatibility during the transition. [new-style command support]: https://reviews.llvm.org/D81689
f35cf16
to
5f7b793
Compare
https://reviews.llvm.org/D81689 has now landed, and I've now made the change to preserve the existing crt1.c and move the new one into crt1-command.c so that one WASI libc build can support both modes, to avoid the need to depend on the LLVM version. |
@@ -276,6 +276,7 @@ _exit | |||
_flushlbf | |||
_initialize | |||
_start | |||
_start |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does _start
appear twice now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's defined in crt1.o and crt1-reactor.o. Programs will only use one or the other, but the script which generates defined-symbols.txt doesn't know that.
This switches Rust's WASI target to use crt1-command.o instead of crt1.o, which enables support for new-style commands. By default, new-style commands work the same way as old-style commands, so nothing immediately changes here, but this will be needed by later changes to enable support for typed arguments. See here for more information on new-style commands: - WebAssembly/wasi-libc#203 - https://reviews.llvm.org/D81689
…chton WASI: Switch to crt1-command.o to enable support for new-style commands This switches Rust's WASI target to use crt1-command.o instead of crt1.o, which enables support for new-style commands. By default, new-style commands work the same way as old-style commands, so nothing immediately changes here, but this will be needed by later changes to enable support for typed arguments. See here for more information on new-style commands: - WebAssembly/wasi-libc#203 - https://reviews.llvm.org/D81689 r? `@alexcrichton`
…chton WASI: Switch to crt1-command.o to enable support for new-style commands This switches Rust's WASI target to use crt1-command.o instead of crt1.o, which enables support for new-style commands. By default, new-style commands work the same way as old-style commands, so nothing immediately changes here, but this will be needed by later changes to enable support for typed arguments. See here for more information on new-style commands: - WebAssembly/wasi-libc#203 - https://reviews.llvm.org/D81689 r? ``@alexcrichton``
…chton WASI: Switch to crt1-command.o to enable support for new-style commands This switches Rust's WASI target to use crt1-command.o instead of crt1.o, which enables support for new-style commands. By default, new-style commands work the same way as old-style commands, so nothing immediately changes here, but this will be needed by later changes to enable support for typed arguments. See here for more information on new-style commands: - WebAssembly/wasi-libc#203 - https://reviews.llvm.org/D81689 r? ```@alexcrichton```
The core idea of new-style commands is that all function exports are command entrypoints, and they expect to be called on a fresh instance which lives only for the direction of the call. This is a generalization of the existing `_start` convention, which already has the expectation of a fresh instance which lives only for the direction of the call, and is one of the pieces need to enable user-defined command entrypoints which don't take string arguments and don't return an i32 status code. To show how this works in practice, the following patches implement this new behavior in wasm-ld and wasi-libc: - https://reviews.llvm.org/D81689 - WebAssembly/wasi-libc#203
The core idea of new-style commands is that all function exports are command entrypoints, and they expect to be called on a fresh instance which lives only for the direction of the call. This is a generalization of the existing `_start` convention, which already has the expectation of a fresh instance which lives only for the direction of the call, and is one of the pieces need to enable user-defined command entrypoints which don't take string arguments and don't return an i32 status code. To show how this works in practice, the following patches implement this new behavior in wasm-ld and wasi-libc: - https://reviews.llvm.org/D81689 - WebAssembly/wasi-libc#203
This enables new-style command support. Instead of calling
__wasm_call_ctors
and__wasm_call_dtors
directly, this letswasm-ld automatically call them.
And, this comments out a use of "protected" visibility, since
WebAssembly doesn't support it.