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

Updates to wasm2obj to produce stubs for C code #46

Closed

Conversation

yurydelendik
Copy link
Contributor

@yurydelendik yurydelendik commented Jan 25, 2019

  • adds ability to manipulate VMContext from C code (generate .h and .c stubs)
  • fixes wasm2obj linking
  • fixes data segments generation

P.S. some landed at #50

This was referenced Jan 25, 2019
@sunfishcode
Copy link
Member

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 Instance::new to be refactored to separate allocation from initialization so that the .o files could just call the initialization routine, but that's probably a good idea anyway.

lib/obj/src/function.rs Outdated Show resolved Hide resolved
lib/obj/src/data_segment.rs Outdated Show resolved Hide resolved
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())
Copy link
Contributor

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 ?

Copy link
Contributor Author

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

@yurydelendik yurydelendik force-pushed the wasm2obj-update1 branch 2 times, most recently from 0d3adda to 53ce2e7 Compare January 31, 2019 23:33
@yurydelendik yurydelendik changed the title [WIP] Updates to wasm2obj to produce .o files and stubs for C code Updates to wasm2obj to produce stubs for C code Mar 7, 2019
@yurydelendik
Copy link
Contributor Author

The PR is out of date. The functionality maybe covered later by interface types. Closing.

grishasobol pushed a commit to grishasobol/wasmtime that referenced this pull request Nov 29, 2021
howjmay pushed a commit to howjmay/wasmtime that referenced this pull request Jan 24, 2022
* 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
pchickey pushed a commit to pchickey/wasmtime that referenced this pull request May 16, 2023
dhil added a commit to frank-emrich/wasmtime that referenced this pull request Jul 12, 2023
mooori pushed a commit to mooori/wasmtime that referenced this pull request Dec 20, 2023
…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.
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.

4 participants