wavm / wavm Goto Github PK

View Code? Open in Web Editor NEW

2.6K 2.6K 224.0 15.74 MB

WebAssembly Virtual Machine

Home Page: https://wavm.github.io/

License: BSD 3-Clause "New" or "Revised" License

C++ 65.84% CMake 2.30% Shell 0.53% C 12.40% Assembly 0.11% Dockerfile 0.02% Python 18.80%

wavm's Introduction

WAVM

Getting Started | Building WAVM from Source | Exploring the WAVM source

WAVM is a WebAssembly virtual machine, designed for use in non-browser applications.

Fast

WAVM uses LLVM to compile WebAssembly code to machine code with close to native performance. It can even beat native performance in some cases, thanks to the ability to generate machine code tuned for the exact CPU that is running the code.

WAVM also leverages virtual memory and signal handlers to execute WebAssembly's bounds-checked memory accesses at the same cost as a native, unchecked memory access.

Safe

WAVM prevents WebAssembly code from accessing state outside of WebAssembly virtual machine*, or calling native code that you do not explicitly link with the WebAssembly module.

* WAVM is vulnerable to some side-channel attacks, such as Spectre variant 2. WAVM may add further mitigations for specific side-channel attacks, but it's impractical to guard against all such attacks. You should use another form of isolation, such as OS processes, to protect sensitive data from untrusted WebAssembly code.

WebAssembly 1.0+

WAVM fully supports WebAssembly 1.0, plus many proposed extensions to it:

Portable

WAVM is written in portable C/C++, with a small amount of architecture-specific assembly and LLVM IR generation code.

WAVM is tested on and fully supports X86-64 Windows, MacOS, and Linux. It is designed to run on any POSIX-compatible system, but is not routinely tested on other systems.

Support for AArch64 is a work-in-progress. WAVM mostly works on AArch64 Linux, but with some known bugs with handling WebAssembly stack overflow and partially out-of-bounds stores.

WAVM's runtime requires a 64-bit virtual address space, and so is not portable to 32-bit hosts. However, WAVM's assembler and disassembler work on 32-bit hosts.

Portability Matrix

wavm's People

Contributors

Stargazers

Watchers

Forkers

mcanthony replive fritexvz adelarsq wflk logan-lu affixalex aenohe alexxnica kryndex jayphelps enzoh sensecollective sletz spawn66336 guozhaokui amilajack robertomalatesta zoowii qumeta vincaslt vixledger eosio ultraflowsports keto-coin bithumbcoin renatrazumov kustomzone airbc jakelang maldiohead baerchain echolinktech ramtej cfhh cpporhair vehicleebaer jakirkham vchengsong sudosalim techlord-rce mainarke pylyq metacritical syrusakbary pyzh a4a881d4 hassensaidi happy-ferret dio jplevyak2 piotrsikora kuuldor niming2100 k2 mewbak quangio itsedaff deepankarsharma oday0311 davidwei33li ffcczz cdetrio jplevyak aergoio dalavancloud achalasb faasm mtabz lukebillo dan-eicher duanbing mosjin zhanzr digi-lab freemanzyq honry indietasten jackbro kuustudio linecode time2travel codefishd eggfly vavrusa dwaddington appfws ivu4e hadargreinsmark moneytech matiasinsaurralde qiuzhong topecongiro cyrex562 cybershadow rasata zhutony xxuejie ifyouseewendy mrpre

wavm's Issues

Crash running programs (like helloworld.wast) in Debug mode

This is the crash log of running 'wavm' compiled in Debug mode on the helloworld.wast test. It seems to be related to LLVM. The program correctly runs in Release mode.

==========================
Process: wavm [13839]
Path: /Documents/*/wavm
Identifier: wavm
Version: 0
Code Type: X86-64 (Native)
Parent Process: bash [10885]
Responsible: Terminal [3500]
User ID: 504

Date/Time: 2017-09-03 10:57:00.409 +0200
OS Version: Mac OS X 10.11.6 (15G1611)
Report Version: 11
Anonymous UUID: BA39A75D-51E6-94B4-9E76-2B17CD75D7E0

Time Awake Since Boot: 10000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:

==13839==ERROR: AddressSanitizer: container-overflow on address 0x60700000d291 at pc 0x0001098b5242 bp 0x7fff5812bf10 sp 0x7fff5812b6d0
WRITE of size 11 at 0x60700000d291 thread T0
#0 0x1098b5241 in wrap_memmove (libclang_rt.asan_osx_dynamic.dylib+0x40241)
#1 0x7fff96dc6224 in std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >::__init(char const*, unsigned long) (libc++.1.dylib+0x3f224)
#2 0x108ca2e53 in std::__1::enable_if<__is_forward_iteratorllvm::StringRef*::value, void>::type std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >::__construct_at_endllvm::StringRef*(llvm::StringRef*, llvm::StringRef*, unsigned long) (libRuntime.dylib+0xa92e53)
#3 0x108ca1e0c in llvm::SubtargetFeatures::SubtargetFeatures(llvm::StringRef) (libRuntime.dylib+0xa91e0c)
#4 0x108c9ae30 in llvm::MCSubtargetInfo::InitMCProcessorInfo(llvm::StringRef, llvm::StringRef) (libRuntime.dylib+0xa8ae30)
#5 0x108c9b25f in llvm::MCSubtargetInfo::MCSubtargetInfo(llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::ArrayRefllvm::SubtargetFeatureKV, llvm::ArrayRefllvm::SubtargetFeatureKV, llvm::SubtargetInfoKV const*, llvm::MCWriteProcResEntry const*, llvm::MCWriteLatencyEntry const*, llvm::MCReadAdvanceEntry const*, llvm::InstrStage const*, unsigned int const*, unsigned int const*) (libRuntime.dylib+0xa8b25f)
#6 0x1086dfc55 in llvm::X86_MC::createX86MCSubtargetInfo(llvm::Triple const&, llvm::StringRef, llvm::StringRef) (libRuntime.dylib+0x4cfc55)
#7 0x108944800 in llvm::Target::createMCSubtargetInfo(llvm::StringRef, llvm::StringRef, llvm::StringRef) const (libRuntime.dylib+0x734800)
#8 0x108943a79 in llvm::LLVMTargetMachine::initAsmInfo() (libRuntime.dylib+0x733a79)
#9 0x1086ae376 in llvm::X86TargetMachine::X86TargetMachine(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optionalllvm::Reloc::Model, llvm::CodeModel::Model, llvm::CodeGenOpt::Level) (libRuntime.dylib+0x49e376)
#10 0x1086aefce in llvm::RegisterTargetMachinellvm::X86TargetMachine::Allocator(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optionalllvm::Reloc::Model, llvm::CodeModel::Model, llvm::CodeGenOpt::Level) (libRuntime.dylib+0x49efce)
#11 0x1086fc1d3 in llvm::Target::createTargetMachine(llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optionalllvm::Reloc::Model, llvm::CodeModel::Model, llvm::CodeGenOpt::Level) const (libRuntime.dylib+0x4ec1d3)
#12 0x1086fc0b7 in llvm::EngineBuilder::selectTarget(llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::SmallVectorImpl<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > const&) (libRuntime.dylib+0x4ec0b7)
#13 0x108362439 in LLVMJIT::init() LLVMJIT.cpp:755
#14 0x10841c368 in Runtime::init() Runtime.cpp:11
#15 0x107ad78f4 in commandMain(int, char**) wavm.cpp:245
#16 0x107ad6820 in main CLI.h:166
#17 0x7fff9eac65ac in start (libdyld.dylib+0x35ac)
#18 0x1 ()

0x60700000d291 is located 1 bytes inside of 72-byte region [0x60700000d290,0x60700000d2d8)
allocated by thread T0 here:
#0 0x1098c92bb in wrap__Znwm (libclang_rt.asan_osx_dynamic.dylib+0x542bb)
#1 0x108429e39 in std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >::allocate(unsigned long) new:168
#2 0x108ca2c8b in std::__1::enable_if<(__is_forward_iteratorllvm::StringRef*::value) && (is_constructible<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::iterator_traitsllvm::StringRef*::reference>::value), void>::type std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >::assignllvm::StringRef*(llvm::StringRef*, llvm::StringRef*) (libRuntime.dylib+0xa92c8b)
#3 0x108ca1e0c in llvm::SubtargetFeatures::SubtargetFeatures(llvm::StringRef) (libRuntime.dylib+0xa91e0c)
#4 0x108c9ae30 in llvm::MCSubtargetInfo::InitMCProcessorInfo(llvm::StringRef, llvm::StringRef) (libRuntime.dylib+0xa8ae30)
#5 0x108c9b25f in llvm::MCSubtargetInfo::MCSubtargetInfo(llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::ArrayRefllvm::SubtargetFeatureKV, llvm::ArrayRefllvm::SubtargetFeatureKV, llvm::SubtargetInfoKV const*, llvm::MCWriteProcResEntry const*, llvm::MCWriteLatencyEntry const*, llvm::MCReadAdvanceEntry const*, llvm::InstrStage const*, unsigned int const*, unsigned int const*) (libRuntime.dylib+0xa8b25f)
#6 0x1086dfc55 in llvm::X86_MC::createX86MCSubtargetInfo(llvm::Triple const&, llvm::StringRef, llvm::StringRef) (libRuntime.dylib+0x4cfc55)
#7 0x108944800 in llvm::Target::createMCSubtargetInfo(llvm::StringRef, llvm::StringRef, llvm::StringRef) const (libRuntime.dylib+0x734800)
#8 0x108943a79 in llvm::LLVMTargetMachine::initAsmInfo() (libRuntime.dylib+0x733a79)
#9 0x1086ae376 in llvm::X86TargetMachine::X86TargetMachine(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optionalllvm::Reloc::Model, llvm::CodeModel::Model, llvm::CodeGenOpt::Level) (libRuntime.dylib+0x49e376)
#10 0x1086aefce in llvm::RegisterTargetMachinellvm::X86TargetMachine::Allocator(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optionalllvm::Reloc::Model, llvm::CodeModel::Model, llvm::CodeGenOpt::Level) (libRuntime.dylib+0x49efce)
#11 0x1086fc1d3 in llvm::Target::createTargetMachine(llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optionalllvm::Reloc::Model, llvm::CodeModel::Model, llvm::CodeGenOpt::Level) const (libRuntime.dylib+0x4ec1d3)
#12 0x1086fc0b7 in llvm::EngineBuilder::selectTarget(llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::SmallVectorImpl<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > const&) (libRuntime.dylib+0x4ec0b7)
#13 0x108362439 in LLVMJIT::init() LLVMJIT.cpp:755
#14 0x10841c368 in Runtime::init() Runtime.cpp:11
#15 0x107ad78f4 in commandMain(int, char**) wavm.cpp:245
#16 0x107ad6820 in main CLI.h:166
#17 0x7fff9eac65ac in start (libdyld.dylib+0x35ac)
#18 0x1 ()

SUMMARY: AddressSanitizer: container-overflow (libclang_rt.asan_osx_dynamic.dylib+0x40241) in wrap_memmove
Shadow bytes around the buggy address:
0x1c0e00001a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0e00001a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0e00001a20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0e00001a30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0e00001a40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x1c0e00001a50: fa fa[fc]fc fc fc fc fc fc fc fc fa fa fa fa fa
0x1c0e00001a60: 00 00 00 00 00 00 00 00 00 fa fa fa fa fa 00 00
0x1c0e00001a70: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00
0x1c0e00001a80: 00 00 00 00 00 fa fa fa fa fa 00 00 00 00 00 00
0x1c0e00001a90: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 00
0x1c0e00001aa0: 00 fa fa fa fa fa 00 00 00 00 00 00 00 00 00 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==13839==ABORTING

abort() called

Global Trace Buffer (reverse chronological seconds):
0.991635 libclang_rt.asan_osx_dynamic.dylib 0x00000001098d32a0 Consult syslog for more information.
0.991635 libclang_rt.asan_osx_dynamic.dylib 0x00000001098d3236 Address Sanitizer reported a failure.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff9163bf06 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff9a76a4ec pthread_kill + 90
2 libsystem_c.dylib 0x00007fff9531d6df abort + 129
3 libclang_rt.asan_osx_dynamic.dylib 0x00000001098dc876 __sanitizer::Abort() + 6
4 libclang_rt.asan_osx_dynamic.dylib 0x00000001098b5267 wrap_memmove + 1095
5 libc++.1.dylib 0x00007fff96dc6225 std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >::__init(char const*, unsigned long) + 91
6 libRuntime.dylib 0x0000000108ca2e54 std::__1::enable_if<__is_forward_iteratorllvm::StringRef*::value, void>::type std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >::__construct_at_endllvm::StringRef*(llvm::StringRef*, llvm::StringRef*, unsigned long) + 68
7 libRuntime.dylib 0x0000000108ca1e0d llvm::SubtargetFeatures::SubtargetFeatures(llvm::StringRef) + 123
8 libRuntime.dylib 0x0000000108c9ae31 llvm::MCSubtargetInfo::InitMCProcessorInfo(llvm::StringRef, llvm::StringRef) + 69
9 libRuntime.dylib 0x0000000108c9b260 llvm::MCSubtargetInfo::MCSubtargetInfo(llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::ArrayRefllvm::SubtargetFeatureKV, llvm::ArrayRefllvm::SubtargetFeatureKV, llvm::SubtargetInfoKV const*, llvm::MCWriteProcResEntry const*, llvm::MCWriteLatencyEntry const*, llvm::MCReadAdvanceEntry const*, llvm::InstrStage const*, unsigned int const*, unsigned int const*) + 120
10 libRuntime.dylib 0x00000001086dfc56 llvm::X86_MC::createX86MCSubtargetInfo(llvm::Triple const&, llvm::StringRef, llvm::StringRef) + 1232
11 libRuntime.dylib 0x0000000108944801 llvm::Target::createMCSubtargetInfo(llvm::StringRef, llvm::StringRef, llvm::StringRef) const + 97
12 libRuntime.dylib 0x0000000108943a7a llvm::LLVMTargetMachine::initAsmInfo() + 258
13 libRuntime.dylib 0x00000001086ae377 llvm::X86TargetMachine::X86TargetMachine(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optionalllvm::Reloc::Model, llvm::CodeModel::Model, llvm::CodeGenOpt::Level) + 1595
14 libRuntime.dylib 0x00000001086aefcf llvm::RegisterTargetMachinellvm::X86TargetMachine::Allocator(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optionalllvm::Reloc::Model, llvm::CodeModel::Model, llvm::CodeGenOpt::Level) + 151
15 libRuntime.dylib 0x00000001086fc1d4 llvm::Target::createTargetMachine(llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optionalllvm::Reloc::Model, llvm::CodeModel::Model, llvm::CodeGenOpt::Level) const + 174
16 libRuntime.dylib 0x00000001086fc0b8 llvm::EngineBuilder::selectTarget(llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::SmallVectorImpl<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > const&) + 950
17 libRuntime.dylib 0x000000010836243a LLVMJIT::init() + 1546 (LLVMJIT.cpp:755)
18 libRuntime.dylib 0x000000010841c369 Runtime::init() + 9 (Runtime.cpp:12)
19 wavm 0x0000000107ad78f5 commandMain(int, char**) + 1557 (wavm.cpp:247)
20 wavm 0x0000000107ad6821 main + 529 (CLI.h:166)
21 libdyld.dylib 0x00007fff9eac65ad start + 1

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x00007fff5812ac68 rdx: 0x0000000000000000
rdi: 0x000000000000050f rsi: 0x0000000000000006 rbp: 0x00007fff5812ac90 rsp: 0x00007fff5812ac68
r8: 0x0000000109d96b3d r9: 0x0000000000000012 r10: 0x0000000008000000 r11: 0x0000000000000206
r12: 0x00007fff5812b660 r13: 0x00000001098e624d r14: 0x00007fff7d1c1000 r15: 0x00000001098ea7f4
rip: 0x00007fff9163bf06 rfl: 0x0000000000000206 cr2: 0x00007fff7d1c4118

Logical CPU: 0
Error Code: 0x02000148
Trap Number: 133

Binary Images:
0x107ad2000 - 0x107b2cff7 +wavm (0) <5422C9F5-71B1-3A28-8A7F-91EB4D5AA4E4> /Documents//wavm
0x107b4f000 - 0x107eaeff7 +libWAST.dylib (0) /Documents//libWAST.dylib
0x107fd8000 - 0x108159fef +libWASM.dylib (0) <5C3CFE93-52BF-3FCD-A7BD-06C32EAE9696> /Documents//libWASM.dylib
0x1081e0000 - 0x1081f7fe7 +libEmscripten.dylib (0) /Documents//libEmscripten.dylib
0x108210000 - 0x1090b4fe7 +libRuntime.dylib (0) <519B542F-E97D-3725-8466-0EACA6B0B2D4> /Documents//libRuntime.dylib
0x1096d7000 - 0x109787fef +libIR.dylib (0) <92D7DB9C-E251-3880-B9FF-66D12BB80D5F> /Documents//libIR.dylib
0x1097f1000 - 0x1097f4fff +libLogging.dylib (0) <4DBE006E-FC3F-3204-B449-2E5E0EA87907> /Documents//libLogging.dylib
0x1097fd000 - 0x109838fff +libncurses.6.dylib (0) <242F2626-7460-35C9-8833-567524865F6F> /opt/local/lib/libncurses.6.dylib
0x10984b000 - 0x10985bff7 +libz.1.dylib (0) /opt/local/lib/libz.1.dylib
0x109864000 - 0x10986afe7 +libPlatform.dylib (0) <5C4AAE54-7005-3D6E-98F0-1D9527259F60> /Documents//libPlatform.dylib
0x109875000 - 0x1098ffff7 +libclang_rt.asan_osx_dynamic.dylib (0) <55E12EB4-84E0-3706-8ED6-D0C762A0A9E3> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/7.3.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
0x7fff6de0c000 - 0x7fff6de43a47 dyld (360.22) /usr/lib/dyld
0x7fff8a454000 - 0x7fff8a455ffb libSystem.B.dylib (1226.10.1) <160608FD-B79D-3B49-AFEA-53A10C0C86B3> /usr/lib/libSystem.B.dylib
0x7fff8abd4000 - 0x7fff8abd5fff libsystem_secinit.dylib (20) <32B1A8C6-DC84-3F4F-B8CE-9A52B47C3E6B> /usr/lib/system/libsystem_secinit.dylib
0x7fff8d55b000 - 0x7fff8d563fff libcopyfile.dylib (127) /usr/lib/system/libcopyfile.dylib
0x7fff8dd97000 - 0x7fff8dda2ff7 libcommonCrypto.dylib (60075.50.1) <93732261-34B4-3914-B7A2-90A81A182DBA> /usr/lib/system/libcommonCrypto.dylib
0x7fff9112c000 - 0x7fff911a3feb libcorecrypto.dylib (335.50.1) /usr/lib/system/libcorecrypto.dylib
0x7fff91367000 - 0x7fff91368ffb libremovefile.dylib (41) <552EF39E-14D7-363E-9059-4565AC2F894E> /usr/lib/system/libremovefile.dylib
0x7fff9138c000 - 0x7fff913d2ff7 libauto.dylib (186) <999E610F-41FC-32A3-ADCA-5EC049B65DFB> /usr/lib/libauto.dylib
0x7fff91625000 - 0x7fff91643ff7 libsystem_kernel.dylib (3248.70.3) <69D68230-7793-3D11-B49E-BA3A6D5137B8> /usr/lib/system/libsystem_kernel.dylib
0x7fff91b3f000 - 0x7fff91b6cfff libdispatch.dylib (501.40.12) /usr/lib/system/libdispatch.dylib
0x7fff91efa000 - 0x7fff91efcfff libsystem_coreservices.dylib (19.2) <1B3F5AFC-FFCD-3ECB-8B9A-5538366FB20D> /usr/lib/system/libsystem_coreservices.dylib
0x7fff92d0b000 - 0x7fff92d34fff libsystem_info.dylib (477.50.4) /usr/lib/system/libsystem_info.dylib
0x7fff92f33000 - 0x7fff92f3bffb libsystem_dnssd.dylib (625.60.4) <80189998-32B0-316C-B5C5-53857486713D> /usr/lib/system/libsystem_dnssd.dylib
0x7fff940d4000 - 0x7fff940d5fff libsystem_blocks.dylib (65) <1244D9D5-F6AA-35BB-B307-86851C24B8E5> /usr/lib/system/libsystem_blocks.dylib
0x7fff9414a000 - 0x7fff9414cff7 libquarantine.dylib (80) /usr/lib/system/libquarantine.dylib
0x7fff952bf000 - 0x7fff9534cfef libsystem_c.dylib (1082.60.1) <28733D22-553E-3CBC-8D2C-EDCEB46E46AF> /usr/lib/system/libsystem_c.dylib
0x7fff96103000 - 0x7fff96107fff libcache.dylib (75) <9548AAE9-2AB7-3525-9ECE-A2A7C4688447> /usr/lib/system/libcache.dylib
0x7fff96197000 - 0x7fff961a0ff3 libsystem_notify.dylib (150.40.1) /usr/lib/system/libsystem_notify.dylib
0x7fff962ef000 - 0x7fff96300ff7 libsystem_trace.dylib (201.10.3) <4F626911-011B-3E9C-8D61-C5EBA79013F0> /usr/lib/system/libsystem_trace.dylib
0x7fff9644e000 - 0x7fff96465ff7 libsystem_asl.dylib (323.50.1) <41F8E11F-1BD0-3F1D-BA3A-AA1577ED98A9> /usr/lib/system/libsystem_asl.dylib
0x7fff96c67000 - 0x7fff96c90ff7 libxpc.dylib (765.70.1) <4FB1311F-4032-3F56-BF0B-CFF45D78FB01> /usr/lib/system/libxpc.dylib
0x7fff96d87000 - 0x7fff96ddaff7 libc++.1.dylib (120.1) <8FC3D139-8055-3498-9AC5-6467CB7F4D14> /usr/lib/libc++.1.dylib
0x7fff97921000 - 0x7fff97923ff7 libsystem_configuration.dylib (802.40.13) <3DEB7DF9-6804-37E1-BC83-0166882FF0FF> /usr/lib/system/libsystem_configuration.dylib
0x7fff98d20000 - 0x7fff98d23fff libsystem_sandbox.dylib (460.60.3) <2DDCB4AF-3037-34E5-A451-6846AFB9B85C> /usr/lib/system/libsystem_sandbox.dylib
0x7fff990bb000 - 0x7fff990bbff7 libkeymgr.dylib (28) <8371CE54-5FDD-3CE9-B3DF-E98C761B6FE0> /usr/lib/system/libkeymgr.dylib
0x7fff99e27000 - 0x7fff99e27ff7 liblaunch.dylib (765.70.1) <96D7C3EE-82E2-39AB-870F-B317A030E86D> /usr/lib/system/liblaunch.dylib
0x7fff99e28000 - 0x7fff99e30fff libsystem_networkextension.dylib (385.40.36) <66095DC7-6539-38F2-95EE-458F15F6D014> /usr/lib/system/libsystem_networkextension.dylib
0x7fff99e31000 - 0x7fff9a193f3f libobjc.A.dylib (680) <7489D2D6-1EFD-3414-B18D-2AECCCC90286> /usr/lib/libobjc.A.dylib
0x7fff9a194000 - 0x7fff9a1b0ff7 libsystem_malloc.dylib (67.40.1) <5748E8B2-F81C-34C6-8B13-456213127678> /usr/lib/system/libsystem_malloc.dylib
0x7fff9a764000 - 0x7fff9a76dff7 libsystem_pthread.dylib (138.10.4) <3DD1EF4C-1D1B-3ABF-8CC6-B3B1CEEE9559> /usr/lib/system/libsystem_pthread.dylib
0x7fff9a8f3000 - 0x7fff9a959ff7 libsystem_network.dylib (583.50.1) /usr/lib/system/libsystem_network.dylib
0x7fff9b95a000 - 0x7fff9b95bfff libDiagnosticMessagesClient.dylib (100) <4243B6B4-21E9-355B-9C5A-95A216233B96> /usr/lib/libDiagnosticMessagesClient.dylib
0x7fff9b95c000 - 0x7fff9b964fef libsystem_platform.dylib (74.40.2) <29A905EF-6777-3C33-82B0-6C3A88C4BA15> /usr/lib/system/libsystem_platform.dylib
0x7fff9bcea000 - 0x7fff9bd19ffb libsystem_m.dylib (3105) <08E1A4B2-6448-3DFE-A58C-ACC7335BE7E4> /usr/lib/system/libsystem_m.dylib
0x7fff9e498000 - 0x7fff9e49dff7 libmacho.dylib (875.1) <318264FA-58F1-39D8-8285-1F6254EE410E> /usr/lib/system/libmacho.dylib
0x7fff9e6ed000 - 0x7fff9e717ff7 libc++abi.dylib (307.4) /usr/lib/libc++abi.dylib
0x7fff9e74f000 - 0x7fff9e754ff3 libunwind.dylib (35.3) /usr/lib/system/libunwind.dylib
0x7fff9eac3000 - 0x7fff9eac6ffb libdyld.dylib (360.22) <7C1BBC59-FA8A-3BDF-B209-02167832E7D1> /usr/lib/system/libdyld.dylib
0x7fff9ee1c000 - 0x7fff9ee33ff7 libsystem_coretls.dylib (83.40.5) /usr/lib/system/libsystem_coretls.dylib
0x7fff9f0ea000 - 0x7fff9f0eaff7 libunc.dylib (29) /usr/lib/system/libunc.dylib
0x7fff9f7e7000 - 0x7fff9f7eeff7 libcompiler_rt.dylib (62) /usr/lib/system/libcompiler_rt.dylib

External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 2
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 322310
thread_create: 0
thread_set_state: 213

VM Region Summary:
ReadOnly portion of Libraries: Total=127.3M resident=0K(0%) swapped_out_or_unallocated=127.3M(100%)
Writable regions: Total=14.0T written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=14.0T(100%)

                              VIRTUAL   REGION

REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Activity Tracing 2048K 2
Kernel Alloc Once 4K 2
MALLOC 4K 2
Performance tool data 6.0T 106 not counted in TOTAL below
Performance tool data (reserved) 14.0T 38 reserved VM address space (unallocated)
STACK GUARD 56.0M 2
Stack 8192K 2
VM_ALLOCATE 80.0G 5
VM_ALLOCATE (reserved) 32.0M 3 reserved VM address space (unallocated)
__DATA 15.7M 65
__LINKEDIT 98.2M 14
__TEXT 29.0M 53
shared memory 12K 4
=========== ======= =======
TOTAL 80.2G 143
TOTAL, minus reserved VM space 16777202.1T 143

Model: MacBookPro11,4, BootROM MBP114.0172.B16, 4 processors, Intel Core i7, 2,2 GHz, 16 GB, SMC 2.29f24
Graphics: Intel Iris Pro, Intel Iris Pro, Built-In
Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x802C, 0x31364B544631473634485A2D314736453120
Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1600 MHz, 0x802C, 0x31364B544631473634485A2D314736453120
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x152), Broadcom BCM43xx 1.0 (7.21.95.175.1a6)
Bluetooth: Version 4.4.6f1 17910, 3 services, 18 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM0512G, 500,28 GB
USB Device: USB 3.0 Bus
USB Device: Apple Internal Keyboard / Trackpad
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus: MacBook Pro, Apple Inc., 27.1

IR::FunctionValidationContext::catch_all(IR::NoImm) heap-buffer-overflow parsing running wasm file causing crash

Hello Reporting some possible vul @WebAssembly Virtual Machine

Vul Description:
IR::FunctionValidationContext::catch_all(IR::NoImm) heap-buffer-overflow parsing running wasm file causing crash

Impact Products version:
the latest wavm lib

git log --pretty=oneline
commit 2173c46

crash detail:

=================================================================
==24366==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000007478 at pc 0x0000004d42a9 bp 0x7ffde0436550 sp 0x7ffde0435d00
READ of size 8 at 0x604000007478 thread T0
#0 0x4d42a8 in __asan_memcpy /local/mnt/workspace/clang_nightly/plain/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23:3
#1 0x7f4fb18eb7d7 in IR::FunctionValidationContext::catch_all(IR::NoImm) (/home/limingzheng/WAVM/build_debugclangasan/Source/IR/libIR.so+0x11c7d7)
#2 0x7f4fb1887ead in IR::CodeValidationStream::catch_all(IR::NoImm) (/home/limingzheng/WAVM/build_debugclangasan/Source/IR/libIR.so+0xb8ead)
#3 0x7f4fb3dcc519 in WASM::serializeFunctionBody(Serialization::InputStream&, IR::Module&, IR::FunctionDef&) (/home/limingzheng/WAVM/build_debugclangasan/Source/WASM/libWASM.so+0xa7519)
#4 0x7f4fb3ee2316 in void WASM::serializeCodeSectionSerialization::InputStream(Serialization::InputStream&, IR::Module&)::{lambda(Serialization::InputStream&)#1}::operator()(Serialization::InputStream&) const (/home/limingzheng/WAVM/build_debugclangasan/Source/WASM/libWASM.so+0x1bd316)
#5 0x7f4fb3ee1cc1 in void WASM::serializeSection<void WASM::serializeCodeSectionSerialization::InputStream(Serialization::InputStream&, IR::Module&)::{lambda(Serialization::InputStream&)#1}>(Serialization::InputStream&, WASM::SectionType, void WASM::serializeCodeSectionSerialization::InputStream(Serialization::InputStream&, IR::Module&)::{lambda(Serialization::InputStream&)#1}) (/home/limingzheng/WAVM/build_debugclangasan/Source/WASM/libWASM.so+0x1bccc1)
#6 0x7f4fb3e1d915 in void WASM::serializeCodeSectionSerialization::InputStream(Serialization::InputStream&, IR::Module&) (/home/limingzheng/WAVM/build_debugclangasan/Source/WASM/libWASM.so+0xf8915)
#7 0x7f4fb3dce589 in WASM::serializeModule(Serialization::InputStream&, IR::Module&) (/home/limingzheng/WAVM/build_debugclangasan/Source/WASM/libWASM.so+0xa9589)
#8 0x7f4fb3dce97c in WASM::serialize(Serialization::InputStream&, IR::Module&) (/home/limingzheng/WAVM/build_debugclangasan/Source/WASM/libWASM.so+0xa997c)
#9 0x511845 in loadBinaryModule(std::string const&, IR::Module&) (/home/limingzheng/WAVM/build_debugclangasan/bin/wavm+0x511845)
#10 0x509409 in loadModule(char const*, IR::Module&) (/home/limingzheng/WAVM/build_debugclangasan/bin/wavm+0x509409)
#11 0x50632c in run(CommandLineOptions const&) (/home/limingzheng/WAVM/build_debugclangasan/bin/wavm+0x50632c)
#12 0x505a4c in main (/home/limingzheng/WAVM/build_debugclangasan/bin/wavm+0x505a4c)
#13 0x7f4fafb4eb34 in __libc_start_main (/lib64/libc.so.6+0x21b34)
#14 0x434aa1 in _start (/home/limingzheng/WAVM/build_debugclangasan/bin/wavm+0x434aa1)

0x604000007478 is located 7 bytes to the right of 33-byte region [0x604000007450,0x604000007471)
allocated by thread T0 here:
#0 0x501f32 in operator new(unsigned long) /local/mnt/workspace/clang_nightly/plain/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_new_delete.cc:92:3
#1 0x7f4fb01c1c78 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (/lib64/libstdc++.so.6+0xbdc78)
#2 0x7f4fb01c3967 in std::basic_string<char, std::char_traits, std::allocator >::basic_string(char const*, std::allocator const&) (/lib64/libstdc++.so.6+0xbf967)

SUMMARY: AddressSanitizer: heap-buffer-overflow /local/mnt/workspace/clang_nightly/plain/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23:3 in __asan_memcpy
Shadow bytes around the buggy address:
0x0c087fff8e30: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 03 fa
0x0c087fff8e40: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 01 fa
0x0c087fff8e50: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 01 fa
0x0c087fff8e60: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 01 fa
0x0c087fff8e70: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 01 fa
=>0x0c087fff8e80: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 01[fa]
0x0c087fff8e90: fa fa 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
0x0c087fff8ea0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8eb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8ec0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c087fff8ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==24366==ABORTING

IRFunctionValidationContextcatch_all(IRNoImm)7_3.zip

Use GCC printf checking attribute to detect misuse of the various formatting functions

GCC has a function attribute __attribute__((format(printf,..)) that can be used to make the compiler detect misuses of varargs in printf-like functions. WAVM should use it to defend against mistakes.

IR::FunctionValidationContext::end(IR::NoImm) heap-buffer-overflow parsing running wasm file causing crash

IRFunctionValidationContextend heapoverflow2_7.zip

__gnu_cxx::new_allocator<IR::ValueType>::allocate(unsigned long, void const*) parsing running wasm file causing crash

__gnu_cxxnew_allocatorIRValueTypeallocate(unsigned long, void const) cauing crash3_7.zip

WAST::lex parsing wast file causing heap-buffer-overflow

WAST::lex parsing wast file causing heap-buffer-overflow leading possible local code exec
WASTlex-heapbufferoverflow.zip

use llvm 5

It would be nice to support llvm v5

Compile to .bc file error on "clang --target=wasm32..."

I have a simple code:

  #include <stdio.h>
  int main() { printf("Hello World!\n"); return 0; }

Its Ok to compile, like this clang hello.cpp -c -O3 -emit-llvm -o hello.bc
But a error occurred after adding the param --target=wasm32

hello.cpp:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>

What's the matter？How to do, please

Translate numeric intrinsics to LLVM IR

These WASM operations are currently implemented by calling an intrinsic implemented in WAVM's C++ code:

f32.ceil/f64.ceil
f32.floor/f64.floor
f32.trunc/f64.trunc
f32.nearest/f64.nearest

It should be faster to lower these operations to the equivalent LLVM IR operations.

libRuntime.so!llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) parsing running wasm file causing crash in runtime

InstructionCombiningPass_runOnFunction_crashin_libRuntime11_1.zip

WAVM does not allow WAST files that omit the enclosing (module ...)

Omitting the (module) wrapper is allowed by the spec, so WAVM should allow it.

The SIMD saturating float->int casts don't correctly handle infinities

These tests don't yet pass:

https://github.com/AndrewScheidecker/WAVM/blob/b76e49c048b45cdb65f831b105e35f87285e5220/Test/WAVM/simd.wast#L73

https://github.com/AndrewScheidecker/WAVM/blob/b76e49c048b45cdb65f831b105e35f87285e5220/Test/WAVM/simd.wast#L117

Emit LLVM external globals instead of literals for instance-specific values

Various things currently emit literal values in the LLVM IR for instance-specific values:

The intrinsic function pointer in emitRuntimeIntrinsic
The expected FunctionType* in call_indirect
Immutable globals
Imported function pointers
Exception type pointers

Emitting these as globals would allow the compiled code to be reused for different ModuleInstances, and for the compiled code to be reused across multiple runs of WAVM.

One possible trick for <=64-bit values is to use the LLVM global address as the value instead of loading t he value from the address. This might need the absolute_symbol metadata on the global variable.

Implement diagnostic stack traces on OSX

Linux and Windows provide nice stack traces for runtime exceptions, but OSX does not. I think the right way to do this is using libunwind, but I'm not sure.

Tests failing to execute with access violation

I may be doing something wrong here, but when I try torun "echo.wast" or "helloworld.wast" tests they are crashing and throw some access violation error:

wavm .\helloworld.wast
Unhandled runtime exception: access violation
Call stack:
  Emscripten::instantiate
  run
  main
  invoke_main
  __scrt_common_main_seh
  __scrt_common_main
  mainCRTStartup
  BaseThreadInitThunk
  RtlUserThreadStart

this has likely started happening after the fix for: #83

It works fine with this commit:

commit fae4a65846b4288adc85616a540b8b3d0f985d91
Author: Andrew Scheidecker <[email protected]>
Date:   Thu Apr 19 10:36:39 2018 -0400

    Fix compile error on older Clang versions

Garbage collection doesn't scan functions on the stack

WAVM uses garbage collection to detect when the it is safe to free the compiled code for a module. However, it does not scan functions on the stack, so if you call a function through a table, then clear the table element and trigger garbage collection before returning from that function, it may be garbage collected despite still being referenced.

WAVM can already reliably walk the functions on the stack on Windows and Linux, but not OSX. Once that is implemented, it should be possible to make the garbage collector scan references to functions on the stack:

When starting the garbage collection mark phase, trigger a stack walk in all threads that may execute WASM code.
Use the LLVMJIT JITSymbol to map instruction pointers from the stack walks back to the corresponding FunctionInstance objects and mark them as active.

loadModule(char const*, IR::Module&) parsing wast file causing heap-buffer-overflow

loadModule(char const*, IR::Module&) parsing wast file causing heap-buffer-overflow
leading possible local code exec
loadModule-heapbufferoverflow.zip

The parsing of data/element segment offsets doesn't exactly match the spec

For example, the spec for table segments specifies that the segment offset may be either an expression wrapped in an offset tag, or a single instruction: ('(' 'offset' (instr)* ')') | instr

WAVM parses ('(' 'offset' expr ')') | expr.

Since there aren't any allowed multi-instruction offset expressions, the practical difference here is just that WAVM expects a parenthesized "expression" instead of an "instruction" that may or may not be parenthesized.

Build failed with llvm5.0

Build master branch(4515313) on ubuntu 16.04 with llvm5.0 and cmake 3.5.1 failed. I execute the following command:

cd WAVM
cmake .
make

Output:

[  2%] Building CXX object Source/Platform/CMakeFiles/Platform.dir/POSIX.cpp.o
[  4%] Building CXX object Source/Platform/CMakeFiles/Platform.dir/Windows.cpp.o
[  6%] Linking CXX shared library libPlatform.so
[  6%] Built target Platform
[  8%] Building CXX object Source/Logging/CMakeFiles/Logging.dir/Logging.cpp.o
[ 10%] Linking CXX shared library libLogging.so
[ 10%] Built target Logging
[ 13%] Building CXX object Source/IR/CMakeFiles/IR.dir/DisassemblyNames.cpp.o
[ 15%] Building CXX object Source/IR/CMakeFiles/IR.dir/Operators.cpp.o
[ 17%] Building CXX object Source/IR/CMakeFiles/IR.dir/Types.cpp.o
[ 19%] Building CXX object Source/IR/CMakeFiles/IR.dir/Validate.cpp.o
[ 21%] Linking CXX shared library libIR.so
[ 21%] Built target IR
[ 23%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/Exception.cpp.o
[ 26%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/Intrinsics.cpp.o
[ 28%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/Linker.cpp.o
[ 30%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/LLVMEmitIR.cpp.o
[ 32%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/LLVMJIT.cpp.o
[ 34%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/LLVMWin64EH.cpp.o
[ 36%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/Memory.cpp.o
[ 39%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/ModuleInstance.cpp.o
[ 41%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/ObjectGC.cpp.o
[ 43%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/Runtime.cpp.o
[ 45%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/Table.cpp.o
[ 47%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/Threads.cpp.o
[ 50%] Building CXX object Source/Runtime/CMakeFiles/Runtime.dir/WAVMIntrinsics.cpp.o
[ 52%] Linking CXX shared library libRuntime.so
/usr/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
Source/Runtime/CMakeFiles/Runtime.dir/build.make:454: recipe for target 'Source/Runtime/libRuntime.so' failed
make[2]: *** [Source/Runtime/libRuntime.so] Error 1
CMakeFiles/Makefile2:554: recipe for target 'Source/Runtime/CMakeFiles/Runtime.dir/all' failed
make[1]: *** [Source/Runtime/CMakeFiles/Runtime.dir/all] Error 2
Makefile:94: recipe for target 'all' failed
make: *** [all] Error 2

Unable to compile a binary

I've compiled a cpp source using em++ compiler using the next command line:

em++ Benchmark.cpp -o bm.js -s WASM=1 -s ASSERTIONS=0 -s FORCE_FILESYSTEM=0 -s ALLOW_MEMORY_GROWTH=1 -std=c++11

(Benchmark.cpp is a test from you repository)

wavm is unable to execute the binary:

Generated stub for missing import env.___cxa_uncaught_exception : func ()->i32
Generated stub for missing import env.___map_file : func (i32, i32)->i32
Generated stub for missing import env.___setErrNo : func i32->()
Generated stub for missing import env.___syscall91 : func (i32, i32)->i32
Generated stub for missing import env._getenv : func i32->i32
Generated stub for missing import env._llvm_stackrestore : func i32->()
Generated stub for missing import env._llvm_stacksave : func ()->i32
Unhandled runtime exception: wavm.accessViolation
Call stack:
  host!/Users/********/dev/playground/wasm/wavm/Source/Runtime/libRuntime.dylib!Runtime::throwException(Runtime::ExceptionTypeInstance*, std::__1::vector<IR::UntaggedValue, std::__1::allocator<IR::UntaggedValue> >&&)+69
  host!/Users/********/dev/playground/wasm/wavm/Source/Emscripten/libEmscripten.dylib!Emscripten::getTotalMemory(Runtime::ContextRuntimeData*, Intrinsics::MemoryIdArg, Intrinsics::TableIdArg)+72
  wasm!bm.wasm!<function #806>+33
  wasm!bm.wasm!<function #24>+3156
  wasm!bm.wasm!<function #722>+20
  wasm!bm.wasm!<function #14>+176
  wasm!bm.wasm!<function #9>+128
  wasm!bm.wasm!<function #8>+116
  thnk!()->i32+9
  host!/Users/********/dev/playground/wasm/wavm/Source/Runtime/libRuntime.dylib!Runtime::invokeFunctionChecked(Runtime::Context*, Runtime::FunctionInstance*, std::__1::vector<IR::Value, std::__1::allocator<IR::Value> > const&)+171
  host!/Users/********/dev/playground/wasm/wavm/demo/./wavm!main+3647

Call stack:
  host!/Users/********/dev/playground/wasm/wavm/demo/./wavm!main::$_0::__invoke(Runtime::Exception&&)+51
  host!/Users/********/dev/playground/wasm/wavm/Source/Runtime/libRuntime.dylib!Runtime::globalSignalHandler(Platform::Signal, Platform::CallStack const&)+77
  host!/Users/********/dev/playground/wasm/wavm/Source/Platform/libPlatform.dylib!Platform::terminateHandler()+370
  host!/usr/lib/libc++abi.dylib!std::__terminate(void (*)())+8
  host!/usr/lib/libc++abi.dylib!__cxa_throw+121
  host!/Users/********/dev/playground/wasm/wavm/Source/Platform/libPlatform.dylib!Platform::raisePlatformException(void*)+59
  host!/Users/********/dev/playground/wasm/wavm/Source/Runtime/libRuntime.dylib!Runtime::throwException(Runtime::ExceptionTypeInstance*, std::__1::vector<IR::UntaggedValue, std::__1::allocator<IR::UntaggedValue> >&&)+69
  host!/Users/********/dev/playground/wasm/wavm/Source/Emscripten/libEmscripten.dylib!Emscripten::getTotalMemory(Runtime::ContextRuntimeData*, Intrinsics::MemoryIdArg, Intrinsics::TableIdArg)+72
  <unknown function>
  <unknown function>
  <unknown function>
  <unknown function>
  <unknown function>
  <unknown function>
  <unknown function>
  host!/Users/********/dev/playground/wasm/wavm/Source/Runtime/libRuntime.dylib!Runtime::invokeFunctionChecked(Runtime::Context*, Runtime::FunctionInstance*, std::__1::vector<IR::Value, std::__1::allocator<IR::Value> > const&)+171
  host!/Users/********/dev/playground/wasm/wavm/demo/./wavm!main+3647

FunctionValidationContext::popAndValidateOperand(char const*, IR::ValueType) heap-buffer-overflow parsing running wasm file causing crash

popAndValidateOperand leading heap buffer overflow1_13.zip

Improve build instructions for Linux/OSX

It will be great to have better OS X build instructions for this project. Currently, you got only detailed Windoz ones.

Emit branch-less saturate for table accesses instead of relying on page faults

The code currently reserves enough virtual address space to access any 32-bit table index without generating an address outside the reservation. Since each table element is 16 bytes, that's 64GB of address-space. With WASM likely supporting multiple tables/module, and eventually 64-bit table indices, this approach doesn't scale very well.

A more practical alternative might be to only reserve the virtual addresses for the maximum table size, and then use a branch-less saturate to clamp the address generated for an index to the reserved addresses. A guard page, or canary element at the end of the table can be used to detect out-of-bounds indices that have been saturated.

Building against Clang 3.7 issues

When building with clang 3.7 on debian using the 3.7 packages from llvm I get a bunch of build failures

WAVM/Source/WebAssembly/WebAssemblyTextParse.cpp:176:30: error: moving a temporary object prevents copy
elision [-Werror,-Wpessimizing-move]
outVariables.emplace_back(std::move(Variable({type,nameCopy})));
^
WAVM/Source/WebAssembly/WebAssemblyTextParse.cpp:176:30: note: remove std::move call here
outVariables.emplace_back(std::move(Variable({type,nameCopy})));
^~~~~~~~~~ ~

...
(and a bunch more against various std::move usage)
...

zlib, and libedit also are not listed dependency so linking fails until you install them.

Linking CXX shared library libRuntime.so
/usr/bin/ld: cannot find -lz

compile with afl-fast-clang failed

how to solve the problem?

Crash when hitting CTRL+C in debug build on Windows

Using CTRL+C to terminate a debug build of WAVM on Windows triggers a debug heap error when LLVMContext tries to free an "owned module".

HEAP[wavm.exe]: Invalid address specified to RtlValidateHeap( 00000218BACE0000, 00000218BAD554D0 )

	ucrtbased.dll!_CrtIsValidHeapPointer(const void * block) Line 1407	C++	Symbols loaded.
 	ucrtbased.dll!free_dbg_nolock(void * const block, const int block_use) Line 904	C++	Symbols loaded.
 	ucrtbased.dll!_free_dbg(void * block, int block_use) Line 1030	C++	Symbols loaded.
 	Runtime.dll!operator delete(void * block) Line 36	C++	Symbols loaded.
 	Runtime.dll!operator delete(void * block, unsigned __int64 __formal) Line 31	C++	Symbols loaded.
 	Runtime.dll!llvm::Module::`scalar deleting destructor'(unsigned int)	C++	Symbols loaded.
 	Runtime.dll!llvm::LLVMContextImpl::~LLVMContextImpl() Line 49	C++	Symbols loaded.
 	Runtime.dll!llvm::LLVMContextImpl::`scalar deleting destructor'(unsigned int)	C++	Symbols loaded.
 	Runtime.dll!llvm::LLVMContext::~LLVMContext() Line 100	C++	Symbols loaded.
 	Runtime.dll!LLVMJIT::`dynamic atexit destructor for 'context''()	C++	Symbols loaded.
 	ucrtbased.dll!_execute_onexit_table::__l2::<lambda>() Line 206	C++	Symbols loaded.

CMake complains about missing /WASM/WASM.h

Compilation error on master

Compiling on OSX El Capitan :

clang++ --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Got this :

Scanning dependencies of target IR
[ 11%] Building CXX object Source/IR/CMakeFiles/IR.dir/DisassemblyNames.cpp.o
In file included from /Documents/WAVM/Source/IR/DisassemblyNames.cpp:5:
In file included from /Documents/WAVM/Include/IR/Module.h:5:
/Documents/WAVM/Include/IR/Types.h:126:37: error: inline declaration of 'inferValueType<int>' follows non-inline definition
        template<> constexpr IR::ValueType inferValueType<I32>()  { return IR::ValueType::i32; }
                                           ^
/Documents/WAVM/Include/IR/Types.h:126:37: note: previous definition is here
/Documents/WAVM/Include/IR/Types.h:127:37: error: inline declaration of 'inferValueType<unsigned int>' follows non-inline definition
        template<> constexpr IR::ValueType inferValueType<U32>()  { return IR::ValueType::i32; }
                                           ^
/Documents/WAVM/Include/IR/Types.h:127:37: note: previous definition is here
/Documents/WAVM/Include/IR/Types.h:128:37: error: inline declaration of 'inferValueType<long long>' follows non-inline definition
        template<> constexpr IR::ValueType inferValueType<I64>()  { return IR::ValueType::i64; }
                                           ^
/Documents/WAVM/Include/IR/Types.h:128:37: note: previous definition is here
/Documents/WAVM/Include/IR/Types.h:129:37: error: inline declaration of 'inferValueType<unsigned long long>' follows non-inline definition
        template<> constexpr IR::ValueType inferValueType<U64>()  { return IR::ValueType::i64; }
                                           ^
/Documents/WAVM/Include/IR/Types.h:129:37: note: previous definition is here
/Documents/WAVM/Include/IR/Types.h:130:37: error: inline declaration of 'inferValueType<float>' follows non-inline definition
        template<> constexpr IR::ValueType inferValueType<F32>()  { return IR::ValueType::f32; }
                                           ^
/Documents/WAVM/Include/IR/Types.h:130:37: note: previous definition is here
/Documents/WAVM/Include/IR/Types.h:131:37: error: inline declaration of 'inferValueType<double>' follows non-inline definition
        template<> constexpr IR::ValueType inferValueType<F64>()  { return IR::ValueType::f64; }
                                           ^
/Documents/WAVM/Include/IR/Types.h:131:37: note: previous definition is here
6 errors generated.

Cloning a ModuleInstance ?

In our use case (Using WAVM as a target for the Faust compiler), we typically need to create several ModuleInstance from a given Module. I don't find an explicit ModuleInstance clone method. Should we load the Module again and again and create new 'ModuleInstances' from there ? (so using the instantiateModule) , or is there a way to load/create the given Module once and create several instances from it?

Support for LLVM 6 (tip-of-tree)

I wanted to check out WAVM, and I currently work on LLVM tip-of-tree, so that is the version I have handy (6.0.0svn). Would supporting that be hard? Maybe it would be useful to have an llvm-next branch to allow for staging updrades?

Maybe I'm just being lazy and should just build another copy of the LLVM locally.. ?

Support AArch64 hosts

There are a few components to this:

There's some CPU-specific C and assembly code in Platform, used for forking threads. That needs to be ported to AArch64.
It's necessary to use platform-specific LLVM intrinsics for many SIMD operations (e.g. saturating addition and min/max). WAVM currently only generates SSE intrinsics, but it should instead look at the target architecture and generate the appropriate intrinsics when targeting AArch64.

libRuntime.so!Runtime::instantiateModule Unhandled runtime exception: wavm.invalidSegmentOffset parsing running wasm file causing crash

runtime exception wavm.invalidSegmentOffset15_1.zip

VM running in 32 bit?

Really interesting project - very nice to see a VM detached from the major JS engines. I was wondering what you thought about running the VM in a 32 bit arch (specifically ARM but x86 as well). 64 bit is tough for IoT with typical memory constraints so looking to save there. Presumably the sandboxing relies on a larger address space? What if we did not run arbitrary WASM in the VM but only apps that were constrained in some way? In an IoT app we can ensure running only signed code so true sandboxing less of a concern.

wavm!Errors::unreachable() reached unreachable code parsing running wasm file causing crash

popAndValidateOperand readedunreachable code4_7.zip

Clang/LLVM 3.8

Hi, can you plz check the build against LLVM 3.8? On travis you're running the build with Clang 3.4.0 while linking everything to LLVM 3.8, which is a bit strange.

I'm getting a huge amount of errors with the latest GCC, as well as with Clang 3.8.2.

WAVM -c report error on some simple wast

I wrote a very simple rust wasm module, here is the code:

#[no_mangle]
pub extern "C" fn test(upper: u32) -> u32 {
    let v: Vec<u32> = (0..upper).collect();
    v.iter()
        .map(|n| n * n)
        .take_while(|&n| n < upper)
        .filter(|&n| n % 2 == 1)
        .fold(0, |sum, i| sum + i)
}

I execute the following command to compile and shrink it:

cargo build --target=wasm32-unknown-unknown --release
wasm-gc target/wasm32-unknown-unkown/release/wasm_test.wasm -o wasm_test.gc.wasm

wavm -c passing:

wavm -c wasm_test.gc.wasm

Then, I use binaryen to convert it to wast:

wasm-opt -S wasm_test.gc.wasm -o wasm_test.gc.wast

wavm -c produce the following error:

wavm -c wasm_test.gc.wast
Error parsing WebAssembly text file:
wasm_test.gc.wast:163:18: expected type name or index
  (call_indirect (type $0)
                 ^
wasm_test.gc.wast:1524:24: expected type name or index
        (call_indirect (type $1)
                       ^
wasm_test.gc.wast:1548:25: expected type name or index
         (call_indirect (type $1)
                        ^
wasm_test.gc.wast:2506:27: expected type name or index
           (call_indirect (type $2)
                          ^
wasm_test.gc.wast:2623:23: expected type name or index
       (call_indirect (type $2)
                      ^
wasm_test.gc.wast:3043:21: expected type name or index
     (call_indirect (type $2)
                    ^
wasm_test.gc.wast:3088:19: expected type name or index
   (call_indirect (type $2)
                  ^
wasm_test.gc.wast:3186:21: expected type name or index
     (call_indirect (type $2)
                    ^
wasm_test.gc.wast:3334:18: expected type name or index
  (call_indirect (type $3)
                 ^
wasm_test.gc.wast:3362:19: expected type name or index
   (call_indirect (type $2)
                  ^
wasm_test.gc.wast:3445:21: expected type name or index
     (call_indirect (type $3)
                    ^
wasm_test.gc.wast:3475:21: expected type name or index
     (call_indirect (type $2)
                    ^
wasm_test.gc.wast:3593:20: expected type name or index
    (call_indirect (type $2)
                   ^
wasm_test.gc.wast:3915:19: expected type name or index
   (call_indirect (type $0)
                  ^
wasm_test.gc.wast:4006:22: expected type name or index
      (call_indirect (type $0)
                     ^
wasm_test.gc.wast:4047:22: expected type name or index
      (call_indirect (type $0)
                     ^
wasm_test.gc.wast:4065:21: expected type name or index
     (call_indirect (type $0)
                    ^
wasm_test.gc.wast:4176:20: expected type name or index
    (call_indirect (type $4)
                   ^
wasm_test.gc.wast:5331:29: expected type name or index
             (call_indirect (type $0)
                            ^
wasm_test.gc.wast:5425:38: expected type name or index
                      (call_indirect (type $4)
                                     ^
wasm_test.gc.wast:5442:37: expected type name or index
                     (call_indirect (type $4)
                                    ^
wasm_test.gc.wast:5469:35: expected type name or index
                   (call_indirect (type $4)
                                  ^
wasm_test.gc.wast:5483:34: expected type name or index
                  (call_indirect (type $4)
                                 ^
wasm_test.gc.wast:5526:33: expected type name or index
                 (call_indirect (type $4)
                                ^
wasm_test.gc.wast:5553:32: expected type name or index
                (call_indirect (type $4)
                               ^
wasm_test.gc.wast:5665:25: expected type name or index
         (call_indirect (type $0)
                        ^
wasm_test.gc.wast:5726:21: expected type name or index
     (call_indirect (type $0)
                    ^
wasm_test.gc.wast:5740:20: expected type name or index
    (call_indirect (type $4)
                   ^
wasm_test.gc.wast:5991:19: expected type name or index
   (call_indirect (type $2)
                  ^
wasm_test.gc.wast:6058:18: expected type name or index
  (call_indirect (type $2)
                 ^
wasm_test.gc.wast:6374:21: expected type name or index
     (call_indirect (type $2)
                    ^
wasm_test.gc.wast:6410:20: expected type name or index
    (call_indirect (type $2)
                   ^
wasm_test.gc.wast:6503:21: expected type name or index
     (call_indirect (type $2)
                    ^
wasm_test.gc.wast:6600:21: expected type name or index
     (call_indirect (type $2)
                    ^
wasm_test.gc.wast:6685:21: expected type name or index
     (call_indirect (type $2)
                    ^
wasm_test.gc.wast:6729:19: expected type name or index
   (call_indirect (type $0)
                  ^
wasm_test.gc.wast:6837:22: expected type name or index
      (call_indirect (type $0)
                     ^
wasm_test.gc.wast:6878:22: expected type name or index
      (call_indirect (type $0)
                     ^
wasm_test.gc.wast:6896:21: expected type name or index
     (call_indirect (type $0)
                    ^
wasm_test.gc.wast:7557:33: expected type name or index
                 (call_indirect (type $0)
                                ^
wasm_test.gc.wast:8075:20: expected type name or index
    (call_indirect (type $0)
                   ^
wasm_test.gc.wast:8096:20: expected type name or index
    (call_indirect (type $0)
                   ^
wasm_test.gc.wast:8786:21: expected type name or index
     (call_indirect (type $2)
                    ^
wasm_test.gc.wast:8914:21: expected type name or index
     (call_indirect (type $2)
                    ^
wasm_test.gc.wast:18603:35: expected type name or index
                   (call_indirect (type $0)
                                  ^
wasm_test.gc.wast:18631:34: expected type name or index
                  (call_indirect (type $0)
                                 ^
wasm_test.gc.wast:19010:26: expected type name or index
          (call_indirect (type $0)
                         ^
wasm_test.gc.wast:19059:24: expected type name or index
        (call_indirect (type $0)
                       ^
wasm_test.gc.wast:19076:25: expected type name or index
         (call_indirect (type $0)
                        ^
wasm_test.gc.wast:19225:24: expected type name or index
        (call_indirect (type $0)
                       ^
wasm_test.gc.wast:19250:22: expected type name or index
      (call_indirect (type $0)
                     ^
wasm_test.gc.wast:19267:23: expected type name or index
       (call_indirect (type $0)
                      ^
wasm_test.gc.wast:19513:21: expected type name or index
     (call_indirect (type $0)
                    ^
wasm_test.gc.wast:19542:21: expected type name or index
     (call_indirect (type $0)
                    ^
wasm_test.gc.wast:20140:31: expected type name or index
               (call_indirect (type $0)
                              ^
wasm_test.gc.wast:20459:23: expected type name or index
       (call_indirect (type $0)
                      ^
wasm_test.gc.wast:20791:24: expected type name or index
        (call_indirect (type $0)
                       ^
wasm_test.gc.wast:20816:22: expected type name or index
      (call_indirect (type $0)
                     ^
wasm_test.gc.wast:20834:24: expected type name or index
        (call_indirect (type $0)
                       ^
wasm_test.gc.wast:20869:20: expected type name or index
    (call_indirect (type $0)
                   ^
wasm_test.gc.wast:21867:20: expected type name or index
    (call_indirect (type $4)
                   ^
wasm_test.gc.wast:22678:29: expected type name or index
             (call_indirect (type $4)
                            ^
wasm_test.gc.wast:22695:28: expected type name or index
            (call_indirect (type $4)
                           ^
wasm_test.gc.wast:22712:27: expected type name or index
           (call_indirect (type $4)
                          ^
wasm_test.gc.wast:22726:26: expected type name or index
          (call_indirect (type $4)
                         ^
wasm_test.gc.wast:22769:25: expected type name or index
         (call_indirect (type $4)
                        ^
wasm_test.gc.wast:22796:24: expected type name or index
        (call_indirect (type $4)
                       ^
wasm_test.gc.wast:22810:20: expected type name or index
    (call_indirect (type $4)
                   ^
wasm_test.gc.wast:23402:30: expected type name or index
              (call_indirect (type $0)
                             ^
wasm_test.gc.wast:23863:30: expected type name or index
              (call_indirect (type $4)
                             ^
wasm_test.gc.wast:23945:29: expected type name or index
             (call_indirect (type $0)
                            ^
wasm_test.gc.wast:23963:29: expected type name or index
             (call_indirect (type $4)
                            ^
wasm_test.gc.wast:24027:27: expected type name or index
           (call_indirect (type $0)
                          ^
wasm_test.gc.wast:24443:21: expected type name or index
     (call_indirect (type $0)
                    ^
wasm_test.gc.wast:24457:21: expected type name or index
     (call_indirect (type $0)
                    ^
wasm_test.gc.wast:24481:21: expected type name or index
     (call_indirect (type $4)
                    ^
wasm_test.gc.wast:24618:20: expected type name or index
    (call_indirect (type $4)
                   ^
wasm_test.gc.wast:24748:26: expected type name or index
          (call_indirect (type $0)
                         ^
wasm_test.gc.wast:25120:25: expected type name or index
         (call_indirect (type $0)
                        ^
wasm_test.gc.wast:26414:18: expected type name or index
  (call_indirect (type $0)
                 ^
wasm_test.gc.wast:26431:18: expected type name or index
  (call_indirect (type $0)
                 ^

Binaryen Version: 1.37.35
Rust Version: 1.24.1
wasm_test.gc.wasm.zip
wasm_test.gc.wast.zip

PS: wasm_test.gc.wasm can be correctly parse and invoked by Chrome

Adding CI for Windows

Would be nice to have CI for Windows on this repo. AppVeyor provides a free (and paid for CI service), which could be one option for addressing this.

Why do root objects keep reference counts?

I've been looking through the code, and I can't figure out why Runtime::ObjectImpl has reference count? From what I see this is only used to determine if root objects are reachable, because non-root objects will always have their counts zero.

Would it not be better to maintain a list of rootObjects along with allObjects and instead of adding an overhead on every object created in the program? Are there any cases where root will have more than one reference, and it still wouldn't be possible to tell if it is alive or not?

:FunctionValidationContext::else_(IR::NoImm) heap-buffer-overflow when parsing running wasm file causing crash

IRFunctionValidationContextelse_(IRNoImm) 6_3.zip

Crash on Windows

I built WAVM with Visual Studio 2015 and LLVM 4.0.

Running wavm with any test causes program crash with no console output even when -d is set. GDB reports Thread 1 received signal SIGSEGV, Segmentation fault.

Running Test Test\wast\helloworld.wast gives the following error message.

Test\wast\helloworld.wast:3:2: missing import module="env" export="_fwrite" type="func (i32,i32,i32,i32)->i32"
(module
 ^
Test\wast\helloworld.wast:3:2: missing import module="env" export="memory" type="memory"
(module
 ^
Test\wast\helloworld.wast:3:2: missing import module="env" export="_stdout" type="immutable i32"
(module
 ^
Test\wast\helloworld.wast: testing failed!

Build log: https://ci.appveyor.com/project/rongjiecomputer/wavm/build/1.0.17

What's needed to support microcontrollers?

My end goal is to execute wasm modules on microcontrollers like cortex m4 devices in order to develop embedded software in higher-level programming languages. The codebase looks fairly platform-agnostic. Am I correct in thinking that the main thing that's needed is to add support in Source/Platform? Since often times these devices are running an RTOS like FreeRTOS (which has features like threads,) one could create freertos.cpp and be able to target a wide-range of MCUs.

Does that sound feasible/correct?

Compile WASM functions in parallel

Split the LLVM module created by LLVMJIT for a WASM module into one LLVM module for each WASM function.
Make the global LLVMContext thread-local.
Make LLVMJIT create a job to compile each WASM function, and distribute those jobs across multiple worker threads.
Make sure the object code memory manager doesn't waste too much memory aligning small object sections to page boundaries.

Make FunctionType::get and TupleType::get thread-safe

FunctionType::get and TupleType::get are not currently thread-safe. A first pass would be to just put a lock around accessing the global maps, but that might be unacceptably slow, so it may be necessary to do something more complicated:

Pack simple types into a pointer-sized value so only more complicated types need to go through the unique type maps.
Replace std::map with some lock-free data structure where lookups are fast when the data structure is populated and rarely mutating

How to compile wasm file to be able to run on WAVM?

I would like to compile a c++ file to wasm or wast, so that I am able to run it on WAVM. I have tried Emscripten, but it creates lots of missing exports, most likely because it is meant to be run from the generated .js file.

Benchmark.wast test seems to have been generated from the Benchmark.cpp file, and I would like to do the same.

Thanks

Cannot build on OpenBSD 6.1

Scanning dependencies of target Platform
[ 2%] Building CXX object Source/Platform/CMakeFiles/Platform.dir/POSIX.cpp.o
/home/custodian/workspace/tmp/WAVM/Source/Platform/POSIX.cpp: In function 'void Platform::initThread()':
/home/custodian/workspace/tmp/WAVM/Source/Platform/POSIX.cpp:151:64: error: 'pthread_get_stackaddr_np' was not declared in this scope
stackMaxAddr = (U8*)pthread_get_stackaddr_np(pthread_self());
^
/home/custodian/workspace/tmp/WAVM/Source/Platform/POSIX.cpp: In function 'void Platform::signalHandler(int, siginfo_t*, void*)':
/home/custodian/workspace/tmp/WAVM/Source/Platform/POSIX.cpp:182:40: error: comparison between distinct pointer types 'caddr_t {aka char*}' and 'U8* {aka unsigned char*}' lacks a cast [-fpermissive]
signalType = signalInfo->si_addr >= stackMinAddr && signalInfo->si_addr < stackMaxAddr
^
/home/custodian/workspace/tmp/WAVM/Source/Platform/POSIX.cpp:182:78: error: comparison between distinct pointer types 'caddr_t {aka char*}' and 'U8* {aka unsigned char*}' lacks a cast [-fpermissive]
signalType = signalInfo->si_addr >= stackMinAddr && signalInfo->si_addr < stackMaxAddr
^
*** Error 1 in . (Source/Platform/CMakeFiles/Platform.dir/build.make:63 'Source/Platform/CMakeFiles/Platform.dir/POSIX.cpp.o': cd /home/cust...)
*** Error 1 in . (CMakeFiles/Makefile2:305 'Source/Platform/CMakeFiles/Platform.dir/all')
*** Error 1 in /home/custodian/workspace/tmp/WAVM/release (Makefile:95 'all')

Execute on iOS/Android

Hi,

First congratulation for the work!

Before investing too much time into it, would it be possible to run the VM from an iOS or Android application? This would allow to run wasm programs and interrop with it!

Thanks!

Protect against skipping the stack overflow guard page on non-Windows platforms

This test sometimes fails on non-Windows systems:
https://github.com/AndrewScheidecker/WAVM/blob/master/Test/spec/skip-stack-guard-page.wast

On Windows, functions that allocate more than 4KB on the stack will walk the allocated pages, touching each to ensure that if it outgrows the stack commit, the single guard page will be hit.

Other platforms use more than one guard page to decide when to grow the stack commit, so LLVM doesn't generate the same page walk for them. However, this means that a function that overflows the stack will not reliably fault on the guard page at the end of the stack reserve before accessing other pages beyond it.

This is a security concern for WAVM when executing untrusted code, since an attacker could deliberately overflow the stack in a way that lets it write to memory outside the WASM sandbox.

The challenge in fixing this is that even though LLVM emits stack probes on Windows, it does not provide a way to do so on other platforms. There was at least one stale patch submitted to LLVM to address this, but it didn't go anywhere.

Rust has a similar issue, and they use LLVM segmented stacks as a workaround.

Launching code compiled with emcc

I am trying to load code compiled with emcc (version 1.37.21). So compiling the simple code:

#include <iostream>

int main(int argc,char** argv)
{
    std::cout << "Hello world!\n";
}

with : emcc hello.cpp -s WASM=1 -o hello.js which creates the hello.js and associated hello.wasm files.

The using: wavm hello.wasm fails with missing symbols, like:

Generated stub for missing function import env.enlargeMemory : func ()->i32
Generated stub for missing function import env.getTotalMemory : func ()->i32
Generated stub for missing function import env.abortOnCannotGrowMemory : func ()->i32
...
Runtime exception: reached unreachable code

So I guess the Emscripten runtime is somewhat missing. How can we load code compiled with emcc ?

Use of backtrace() in signal handler dangerous

It's unsafe to use backtrace() in a signal handler.
https://www.gnu.org/software/libc/manual/html_node/Backtraces.html

Trouble using external functions

My Faust generated module uses some math functions, it has the following kind of import:

....
(import "env" "_expf" (func $fimport$0 (param f32) (result f32)))
(import "env" "_powf" (func $fimport$1 (param f32 f32) (result f32)))
(import "env" "_tanf" (func $fimport$2 (param f32) (result f32)))
....

With older version of WAVM, to add the external functions, I was doing:

.....
DEFINE_INTRINSIC_FUNCTION1(env,_expf,_expf,f32,f32,value) { return std::exp(value); }
.....

With the current version I changed the code to:

DEFINE_INTRINSIC_MODULE(env)
DEFINE_INTRINSIC_FUNCTION(env,"_expf",F32,_expf,F32 value) { return std::exp(value); }
...

But I get the following kind of error at runtime and the programs crashes:

Generated stub for missing import env._expf : func (f32)->f32

Any idea of what is still wrong? Thanks.