435: Fix f32/f64 conversion, add tests, and rename conversion method r=syrusakbary a=bjfish
Fixes#415
I believe removing this conversion here caused the regression: https://github.com/wasmerio/wasmer/pull/379/files#diff-5e7e23717d05d1d18be5b2e3b75f454dL158
I've added conversion tests and also renamed `NativeWasmType::{to_bits, from_bits}` to `to_binary/from_binary` because it seemed akward to overload the existing `f32::to_bits` method.
Co-authored-by: Brandon Fish <brandon.j.fish@gmail.com>
429: implement some FS operations for rsign2 r=MarkMcCaskey a=MarkMcCaskey
Get https://github.com/jedisct1/rsign2 working with WASI on Wasmer (for end-to-end tests of wapm)
Current implementation is very hacky, but works! It should have a couple passes of improvement before shipping
Co-authored-by: Mark McCaskey <mark@wasmer.io>
It's safer to check the buffer size is large enough to hold the error
message before creating the slice from raw parts.
Also, this patch remove the need for `last_error`, simplifying the
code a little bit. The `length` variable is casted to `usize` once.
413: Use the new code generator API for LLVM backend. r=syrusakbary a=losfair
Co-authored-by: Brandon Fish <brandon.j.fish@gmail.com>
Co-authored-by: losfair <zhy20000919@hotmail.com>
Co-authored-by: Brandon Fish <bjfish@users.noreply.github.com>
428: Fix Windows crash on caching compiled artifact. r=syrusakbary a=repi
Memory clone function wasn't able to write to new reserved memory object.
Changed so allocating Memory objects with protection flag allocates commited memory. And added unit test to verify that it doedsn't crash anymore.
Not fully sure this is the best solution though, but fixes this specific clone crash.
Co-authored-by: Johan Andersson <repi@repi.se>
Memory clone function wasn't able to write to new reserved memory object.
Changed so allocating Memory objects with protection flag allocates commited memory.
414: Exception logging (win32): Handle error codes correctly, add some more strings r=syrusakbary a=hrydgard
Ran into a situation with an unknown exception from Cranelift (will probably report that one separately). Turns out the signum was "1" though which does not seem to correspond to any of the Windows error codes, except possibly STATUS_GUARD_PAGE which is 0x80000001, but only if we lost the top bit somewhere.
On Windows, exceptions seemed to be trapped by callProtected, which is implemented here: cade9a666f/lib/win-exception-handler/exception_handling/exception_handling.c . It did not seem to correctly store and retrieve the exception code, instead always returning 1: ```longjmp(jmpBuf, 1);```
So I fixed it. And now the log output looks like this:
```
unhandled trap at 1560d5e7bab - code #c0000005: segmentation violation
```
Co-authored-by: Henrik Rydgård <henrik.rydgard@embark-studios.com>
Co-authored-by: Syrus Akbary <me@syrusakbary.com>
Co-authored-by: Mackenzie Clark <mackenzie.a.z.c@gmail.com>
