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.

Sign up for GitHub

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

Jump to bottom

Implement C/C++ bindings #45

Closed
bnjbvr opened this issue Jan 22, 2019 · 3 comments
Closed

Implement C/C++ bindings #45

bnjbvr opened this issue Jan 22, 2019 · 3 comments

Comments

@bnjbvr
Copy link
Member

bnjbvr commented Jan 22, 2019

I know of at least one possible user who would like to embed this project in a C program. I've seen in the project's goals that there was an intent to implement the proposed C integration API, so filing an issue to not forget about this.
@yurydelendik
Copy link
Contributor

I have some wasm2obj fixes (for my pet project) at #46, though it might provide a workaround for this issue.

@gkorland
Copy link

Is there a plan to add such binding?

@alexcrichton
Copy link
Member

Oh this issue is actually slightly out of date! The proposed C API is implemented by the wasmtime crate where building that will generate a dynamic library named wasmtime you can link in, so this is done!

howjmay pushed a commit to howjmay/wasmtime that referenced this issue Jan 24, 2022
@koponen-styra
Make build directories as valid (empty) go packages. (bytecodeallianc…
e5fed01 
…e#45)

go mod vendor will not copy the header and library directory contents
not referred in any go source code. A common workaround is to add "_"
imports to such directories with necessary cgo files, but doing so
requires rendering such directories as valid go packages. This patch
does exactly that.

With this patch, one can vendor the C headers and libraries by
introducing the following imports in the code using the wasmtime-go
bindings.

import (
	_ "github.com/bytecodealliance/wasmtime-go/build/include"
        _ "github.com/bytecodealliance/wasmtime-go/build/linux-x86_64"
        _ "github.com/bytecodealliance/wasmtime-go/build/macos-x86_64"
        _ "github.com/bytecodealliance/wasmtime-go/build/windows-x86_64"
)

Optionally, one could consider introducing these imports to the
"github.com/bytecodealliance/wasmtime-go" package itself.

For more information about the underlying limitation of vendoring, see
for example: golang/go#26366
howjmay pushed a commit to howjmay/wasmtime that referenced this issue Jan 24, 2022
@olivierlemasle
Add directory build/include/wasmtime (bytecodealliance#82)
542c2ac 
* Add build/include/wasmtime

Following the update to Wasmtime's new C API in bytecodealliance#81, the header files are now not
only in build/local, but also in build/local/wasmtime.

This commit adds the directory "build/include/wasmtime" as a valid empty go
package, like it was done in bytecodealliance#45 for the other build directories.

It also addapts `ci/local.sh` to:
- copy the additional header files in build/include/wasmtime
- stop this script from removing the "empty.go" files.

* Import build packages + add CI test for vendoring

- Import build packages, to prevent `go mod vendor` from pruning the build
  directories;
- Update download-wasmtime.py to re-create the "empty.go" files and keep
  the Go packages in "build"
- Add a CI test to check that wasmtime-go can be used by Go projects using
  dependency vendoring

* Fix for Bazel
pchickey pushed a commit to pchickey/wasmtime that referenced this issue May 12, 2023
@dicej
implement wasi-filesystem::readdir and related functions (bytecodea…
359a796 
…lliance#45)

* implement `wasi-filesystem::readdir` and related functions

This adds a `directory_list` test and provides the required host implementation.

I've also added a file length check to the `file_read` test, just to cover a bit
more of the API.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* fix memory corruption in `fd_readdir` polyfill

We were copying `name.len() * 256` bytes instead of just `name.len()` bytes,
which was overwriting other parts of `State` and causing untold havoc.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* check type of entry in `Table::delete`

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>
pchickey pushed a commit to pchickey/wasmtime that referenced this issue May 16, 2023
@dicej
implement wasi-filesystem::readdir and related functions (bytecodea…
3dabe07 
…lliance#45)

* implement `wasi-filesystem::readdir` and related functions

This adds a `directory_list` test and provides the required host implementation.

I've also added a file length check to the `file_read` test, just to cover a bit
more of the API.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* fix memory corruption in `fd_readdir` polyfill

We were copying `name.len() * 256` bytes instead of just `name.len()` bytes,
which was overwriting other parts of `State` and causing untold havoc.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

* check type of entry in `Table::delete`

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>
dhil added a commit to dhil/wasmtime that referenced this issue Jul 12, 2023
@dhil @frank-emrich
Plug some memory leaks (bytecodealliance#45)
87378fd 
---------

Co-authored-by: Frank Emrich <git@emrich.io>
frank-emrich added a commit to frank-emrich/wasmtime that referenced this issue Nov 7, 2023
@frank-emrich
Assertions in generated code print source location (bytecodealliance#45)
c3ab010 
Currently, assertion violations cause programs to unceremoniously crash.

This PR uses the new printing facilitities added in bytecodealliance#43 and combines it with the assertion mechanism, to make assertion violations more informative. The new macros `emit_debug_assert*` are analogous to the corresponding Rust `debug_assert*` macros, replacing already existing functions that we already had for emitting assertions.

What is new is that when `ENABLE_DEBUG_PRINTING` is set, these new assertion macros can now print the source location in the Rust code where they where defined when assertions are violated, making it much easier to identify which assertion was actually violated.

Those macros that assert that a certain relation holds (e.g., `emit_debug_assert_eq`) also print a description of the violation, including the offending values.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@alexcrichton @gkorland @bnjbvr @yurydelendik