-
Notifications
You must be signed in to change notification settings - Fork 15
Command Line
Usage: innative-cmd [-r] [-c] [-i] [-u] [-v] [-f FLAG...] [-l FILE] [-L FILE] [-o FILE] [-a FILE] [-d PATH] [-s [FILE]] [-w [MODULE:]FUNCTION] FILE...
The inNative command line gives you access to an installed runtime's functionality, allowing you to compile, decompile, or run webassembly modules in a variety of ways. The command line accepts a list of WebAssembly files of the form .wasm, .wat or .wast and links them all together based on the provided command line options. It also has additional functionality accessed through certain flags or command line switches. On Linux, it will always use the latest version of the runtime installed on the system. On Windows, the registered runtime should always be the latest version.
Example usage: innative-cmd test.wat -f o3 -r
The command-line assumes both .wat and .wasm files define a single webassembly module, but can only generate useful debugging information from a .wat file (the runtime is not yet capable of automatically serializing binary files for debugging purposes).
.wast files are given special treatment, because they define entire execution environments. Each .wast file, when encountered, will be compiled and have all of it's internal statements executed. If any of these statements fail or cause an error, compilation will fail. Every single module from the .wast file will be included in the resulting library file.
If the compiler finds a start function in two different modules, verification will fail, even if you are building a library. If you are attempting to compile an EXE file and the compiler doesn't find a start function in any module, compilation will fail.
Each option is case-sensitive, and is separated from it's parameter by a space, e.g. -f debug.
If this is specified, the command line will immediately execute the resulting webassembly binary after it has been compiled by loading it into the current process and calling the start function (it will not start a new process). This cannot be specified at the same time as -f LIBRARY, because you can't execute a library. You also cannot specify any command line arguments to pass to the resulting webassembly binary, because webassembly does not understand command line options.
This links a .a or .lib static library with the resulting webassembly binary during the link process (after the webassembly names have been mangled). inNative always links an internal platform implementation to your webassembly binary that knows how to allocate memory on your target system, but you can use this option to expose additional C functions to your webassembly code, or provide an API that mods can link to.
This is a linux-specific option for linking shared libraries at compile time. Unlike windows, which always provides a corresponding .lib file for every .dll, linux directly links .so files at link time. This passes the .so files to the linker using the -l option.
This simply specifies what the output file should be. There is always 1 output file, which is either a library or an executable. inNative will attempt to choose an appropriate file extension for you by default, but using this option will override the default file extension. Remember to wrap the path in quotes if it has a space!
Example: innative-cmd test.wasm -o "../somewhere else/out.exe"
This is an important option that lets you specify one or more flags. While the inNative environment separates standard flags from optimization flags, the command line lets you specify them all at once, for convenience, and sorts them for you. Some of these flags are incompatible with other flags, or other modes, so keep this in mind. inNative Flags provides a complete list of flags, but not all of them can be used on the command line. Check what the abbreviated Command Line form of the flag is (underneath the full name), and if it says "Not Available", it can't be specified on the command line.
Example: innative-cmd ../extern.wasm -f STRICT DEBUG NOINIT -r
Lets you override where inNative thinks the SDK directory is that contains .lib files and testing scripts. Usually only necessary if it gets confused by the working directory.
Lets you specify what the compiler should consider the special C module that indicates "this function is not actually a webassembly module, but is instead from the host itself". These functions will not have their names mangled when being linked. Several compilers seem to prefer using either env or sys, but this should hopefully become unnecessary once host objects are standardized.
A function with a blank module name is always considered a C function, as it is not a valid module name.
Serializes all .wasm modules specified into .wat files. If you only specify 1 .wasm file, you can use the -o option to override the output file. You can use this to generate .wat files from .wasm files that inNative can attach debugging information to. The serializer will attempt to preserve any Name Section debugging information contained in the .wasm file.
This adds an entry to the environment whitelist, which allows an external C function to be accessed by webassembly. To add a traditional C function, simply add it's name:
-w your_c_function
To add a C function that pretends to be from a webassembly module, ensure that it is named correctly according to Name Mangling. Then, add both the module name and the function name:
-w your_module:your_function
To add multiple whitelist entries, simply specify the -w option multiple times.
This is a helper function that lets you manually compile LLVM IR files to webassembly, in case you don't have access to an up-to-date version of LLVM. When this option is specified, the command line assumes that all input files are actually LLVM IR files and merges them all together into a single webassembly module. You can then compile and run the resulting webassembly module, or serialize it using -s.
Some stripped down versions of inNative probably won't contain the LLVM IR -> webassembly compiler, and so this option won't work with those runtimes. It will always work with the developer SDK.
[WINDOWS ONLY]
Instead of immediately compiling the inputs to a native binary, the command line will look for innative-loader.exe, create a new copy (which can be specified using the output file option), and add all webassembly modules, library embeddings, whitelist entries, and flags to it. When run, the resulting EXE will dynamically look for an installed runtime, and use it to compile and run the webassembly modules on-demand. While not included in the SDK, it is possible to compile a loader that has a version of the runtime embedded inside it instead.
This currently only works on windows and is mostly an experiment with creating a generic executable that compiles webassembly on-demand.
Installs the current runtime to the system, registering the version number and updating shortcuts.
Uninstalls the current runtime from the system, removing itself, updating shortcuts, and if there are no other runtime versions on the system, completely removes all file type registrations and other libraries from the system. If it is not the only version, it simply updates the shortcuts to point to the latest version of inNative and removes itself.
Enables detailed log information for debugging purposes.
Lets you specify an alternative linker to use in place of lld. Only used in case lld has a bug and you need your system's linker to perform the final link of object files.