-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Updates to wasm2obj to produce stubs for C code #46
Updates to wasm2obj to produce stubs for C code #46
Conversation
This approach of generating C files that one could then compile for the target is interesting. I'll need to think about this a bit to think about how this will work out. Another possible approach here would be if we could (cross-)compile cranelift-runtime for the target with something like --crate-type=staticlib, and then link that library with the wasm .o files. Then we could make calls into cranelift-runtime to initialize their VMContext contents. That might require |
lib/obj/src/table.rs
Outdated
pub fn emit_table(obj: &mut Artifact, index: usize) -> Result<(), String> { | ||
let name = format!("_table_{}", index); | ||
// FIXME: We need to initialize table using function symbols | ||
obj.define(name, Vec::new()) |
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.
How come the vec is empty here ?
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.
FIXME comment explains the reason
0d3adda
to
53ce2e7
Compare
53ce2e7
to
8bc90b4
Compare
8bc90b4
to
7c16594
Compare
7c16594
to
7b08a3d
Compare
7b08a3d
to
17f1889
Compare
The PR is out of date. The functionality maybe covered later by interface types. Closing. |
* Implement module linking proposal This commit binds the support added in bytecodealliance#2472 to bring support for the module linking to this Go extension. The support here is similar to bytecodealliance/wasmtime-py#47, which is hooking up modules/instances to `Extern` as well as adding dedicated instance/module types. * Update bazel build * Try to fix a Windows CI issue
…generation (bytecodealliance#46) * zkasm: split AdjustSp to separate variants for Reserve and Release stack space * ci: Fail builds when zkasm testing fails * zkasm: fix handling of clobbering registers * zkasm: stack alignment is 8 bytes Given that stack opeerates in numbers of aligned slots, rather then bytes, making sure that the stack is aligned to 8 bytes can’t be more wrong than aligning it to 1.
fixes wasm2obj linkingfixes data segments generationP.S. some landed at #50