When running in embedded environments, threads creation is sometimes
undesirable. This adds a feature to toggle wasmtime's internal thread
creation for parallel compilation.
- put the division in the synthetic instruction as well,
- put the branch table check in the inst's emission code,
- replace OneWayCondJmp by TrapIf vcode instruction,
- add comments describing code generated by the synthetic instructions
When compiling C to WASM with clang-8, __dso_handle is a global
that maybe exported but that currently is not whitelisted along
with __heap_base and _data_end to be handled as allowable depricated
exports. This PR adds the case for __dso_handle.
* wasmtime: Implement `global.{get,set}` for externref globals
We use libcalls to implement these -- unlike `table.{get,set}`, for which we
create inline JIT fast paths -- because no known toolchain actually uses
externref globals.
Part of #929
* wasmtime: Enable `{extern,func}ref` globals in the API
In discussions with @bnjbvr, it came up that generating `OneWayCondBr`s
with explicit, hardcoded PC-offsets as part of lowered instruction
sequences is actually unsafe, because the register allocator *might*
insert a spill or reload into the middle of our sequence. We were
careful about this in some cases but somehow missed that it was a
general restriction. Conceptually, all inter-instruction references
should be via labels at the VCode level; explicit offsets are only ever
known at emission time, and resolved by the `MachBuffer`.
To allow for conditional trap checks without modifying the CFG (as seen
by regalloc) during lowering, this PR instead adds a `TrapIf`
pseudo-instruction that conditionally skips a single embedded trap
instruction. It lowers to the same `condbr label ; trap ; label: ...`
sequence, but without the hardcoded branch-target offset in the lowering
code.
In order to make it more clear what the incoming types are for this translation (e.g. two `I32X4`s narrow to an `I16X8`), this change explicitly sets the type to which to bitcast (if necessary) the incoming values.
This commit fills out documentation for all remaining functions in the C
API, and additionally enables "warn if undocumented" which will fail CI
since warnings are also treated as errors.
* The underlying `R`/`W` doesnt need to be Clone, since we just need to
clone the Arc it sits behind.
* The rights actually shouldn't be behind an Arc - those get mutated
separately in each clone.
This commit adds a bit of a skeleton of what it might look like to
document the C API. Today the C API has virtually zero documentation
because the upstream documentation does not exist and we haven't put a
ton of effort into documenting our own extensions. Given that this is
one of the main vectors we expect users to use Wasmtime, we should make
sure it's thoroughly documented!
I've never really done much documentation generation of C myself before,
but I did a bit of searching and Doxygen seems reasonable proficient for
doing this. This commit sets up what it might look like for Doxygen to
be used for the C API. One nice feature of DOxygen is that we can
document the items in `wasm.h` without actually modifying `wasm.h`. For
those purposes a `doc-wasm.h` file was added here which is where we can
put Wasmtime-specific documentation about `wasm.h`.
There's quite a few functions in the C API so I didn't want to get them
all done before getting consensus on this. I've started some skeletons
of documentation for global types in `wasm.h` and also confirmed that
documentation works for our own `wasmtime.h` and such header files. If
this looks good to everyone and it runs reasonable well on CI then I can
spend more time filling out the rest of the documentation.
This is something I meant to do a long time ago but forgot to get around
to it! This commit updates the top-level documentation of the `wasmtime`
crate to have examples, more words, and generall be a bit more
up-to-date and complete.
* Rename `OFlag`/`AtFlag` to `OFlags`/`AtFlags`.
This makes them consistent with `PollFlags` and common usage of
bitflags types in Rust code in general.
POSIX does tend to use names like `oflag` and `flag`, so this is in mild
disagreement with POSIX style, however I find this particular aspects of
POSIX confusing because these values hold multiple flags.
* rustfmt
Dan Gohman
Nick Fitzgerald
Daiki Ueno
Graham Scheaffer
MaxGraey
Joey Gouly
Davy Duperron
Benjamin Bouvier
Johnnie Birch
Chris Fallin
Chris Fallin
Andrew Brown
Sergei Shulepov
Alex Crichton
Pat Hickey
Pat Hickey
Adam C. Foltzer