How to dynamically link?

[guest271314]

Facebook's Static Hermes compiles JavaScript to a standalone ELF. When compiling the emitted C to that standalone native executable dynamic linking is used

llvm-project/build/bin/clang shermes-permutations.c -O3 \
-I./build_release/lib/config \
-I./hermes-static_h/include -DNDEBUG \
-fno-strict-aliasing -fno-strict-overflow \
-L./build_release/lib \
-L./build_release/jsi \
-L./build_release/tools/shermes \
-lshermes_console \
-Wl,-rpath ./build_release/lib \
-Wl,-rpath ./build_release/jsi \
-Wl,-rpath ./build_release/tools/shermes \
-lm -lhermesvm \
-o shermes-permutations

facebook/hermes#1588

You are seeing errors because compiling for Wasm is not exactly the same as compiling Elf binaries. Specifically, -rpath is an Elf specific option relevant to dynamic linking, so naturally it is not recognized by the Wasm toolchain, which supports neither.

How do I dynamically link using LLVM clang, WASI-SDK clang, or emcc to target WASM using the emitted C source code from shermes?

[sbc100]

Emscripten does support dynamic linking in the form of the -sMAIN_MODULE and -sSIDE_MODULE settings. See https://emscripten.org/docs/compiling/Dynamic-Linking.html.

However unless you application absolutely requires it I would try to instead build without dyanmic linking and link statically. This will almost always be preferable and will result in smaller and faster code on the web.

In other words I would first try to modify the hermes build scripts to avoid dynamic linking when targeting emscripten.

[guest271314]

I'm not sure how to statically link, and build WASM from the C output by shermes using WASI-SDK or LLVM project clang. I tried.

Since I filed this Hermes static_h branch has added WASM support https://github.com/facebook/hermes/blob/static_h/doc/Emscripten.md, see facebook/hermes#1588 (reply in thread). I'm in the process of testing that now.

[guest271314]

I can verify the documentation linked above, when followed, produces the result described with emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.74 (1092ec3).

hermes-builds$ node ./build-wasm/bin/hermes.js hello.js
hello world

hermes-builds$ node ./build-wasm/bin/hermes.js hello.hbc
hello world

The next step is getting the WASM files to work similar to how they do using Bytecode Alliance Javy, that is, using wasmtime and/or WebAssembly without Emscripten (e.g., compiling with was-sdk/bin/clang or llvm-project/build/bin/clang)

javy emit-plugin -o plugin.wasm
javy build -C dynamic -C plugin=plugin.wasm -o nm_javy_permutations.wasm nm_javy_permutations.js
printf '9 362879' | wasmtime run --preload javy_quickjs_provider_v3=../plugin.wasm ../nm_javy_permutations.wasm
362879 of 362879 (0-indexed, factorial 362880) => [8,7,6,5,4,3,2,1,0]

import { readFile } from "node:fs/promises";
import process from "node:process";
import {default as WASI} from "https://gitlab.com/-/snippets/4782260/raw/main/wasi-minimal.js";
import * as fs from "node:fs";
try {
  const [embeddedModule, pluginModule] = await Promise.all([
    compileModule("./nm_javy_permutations.wasm"),
    compileModule("./plugin.wasm"),
  ]);
  const result = await runJavy(embeddedModule, pluginModule);
} catch (e) {
  process.stdout.write(e.message, "utf8");
} finally {
  process.exit();
}
async function compileModule(wasmPath) {
  const bytes = await readFile(new URL(wasmPath, import.meta.url));
  return WebAssembly.compile(bytes);
}
async function runJavy(embeddedModule, pluginModule) {
  try {
    let wasi = new WASI({
      env: {},
      args: [],
      fds: [
        {
          type: 2,
          handle: fs,
        },
        {
          type: 2,
          handle: fs,
        },
        {
          type: 2,
          handle: fs,
        },
      ],
    });

    const pluginInstance = await WebAssembly.instantiate(
      pluginModule,
      { "wasi_snapshot_preview1": wasi.exports },
    );
    const instance = await WebAssembly.instantiate(embeddedModule, {
      "javy_quickjs_provider_v3": pluginInstance.exports,
    });

    wasi.memory = pluginInstance.exports.memory;
    instance.exports._start();
    return;
  } catch (e) {
    if (e instanceof WebAssembly.RuntimeError) {
      if (e) {
        throw new Error(e);
      }
    }
    throw e;
  }
}

printf '9 362879' | deno -A ../run-wasi.js
362879 of 362879 (0-indexed, factorial 362880) => [8,7,6,5,4,3,2,1,0]

Looking at the generated Emscripten .js file and output of wasm-objdump, I'll have to figure out a way to map exports?

Part of build-wasm/bin/shermes.js

var wasmImports = {
  v: ___call_sighandler,
  g: ___syscall_faccessat,
  d: ___syscall_fstat64,
  A: ___syscall_lstat64,
  y: ___syscall_mkdirat,
  B: ___syscall_newfstatat,
  x: ___syscall_openat,
  r: ___syscall_renameat,
  t: ___syscall_rmdir,
  c: ___syscall_stat64,
  b: ___syscall_unlinkat,
  h: __abort_js,
  e: __emscripten_memcpy_js,
  w: __emscripten_runtime_keepalive_clear,
  l: __mmap_js,
  m: __munmap_js,
  q: __setitimer_js,
  j: _clock_time_get,
  o: _emscripten_resize_heap,
  s: _environ_get,
  C: _environ_sizes_get,
  a: _exit,
  f: _fd_close,
  z: _fd_fdstat_get,
  k: _fd_pread,
  u: _fd_read,
  n: _fd_seek,
  p: _fd_write,
  i: _proc_exit,
};
var wasmExports;
createWasm();
var ___wasm_call_ctors = () => (___wasm_call_ctors = wasmExports["E"])();
var _main = Module["_main"] = (a0, a1) =>
  (_main = Module["_main"] = wasmExports["F"])(a0, a1);
var _emscripten_builtin_memalign = (a0, a1) =>
  (_emscripten_builtin_memalign = wasmExports["H"])(a0, a1);
var __emscripten_timeout = (a0, a1) =>
  (__emscripten_timeout = wasmExports["I"])(a0, a1);
var __emscripten_stack_alloc = (a0) =>
  (__emscripten_stack_alloc = wasmExports["J"])(a0);

 ../wabt/bin/wasm-objdump -j Export -x build-wasm/bin/shermes.wasm

shermes.wasm:	file format wasm 0x1

Section Details:

Export[7]:
 - memory[0] -> "D"
 - func[848] <E> -> "E"
 - func[1360] <F> -> "F"
 - table[0] -> "G"
 - func[1582] <H> -> "H"
 - func[1591] <I> -> "I"
 - func[1566] <J> -> "J"

../wabt/bin/wasm-objdump -j Export -x hello-wasm.wasm

hello-wasm.wasm:	file format wasm 0x1

Section Details:

Export[15]:
 - memory[0] -> "aa"
 - func[1278] <ba> -> "ba"
 - func[2200] <ca> -> "ca"
 - table[0] -> "da"
 - func[1506] <ea> -> "ea"
 - func[2212] <fa> -> "fa"
 - func[2196] <ga> -> "ga"
 - func[2195] <ha> -> "ha"
 - func[2167] <ia> -> "ia"
 - func[2166] <ja> -> "ja"
 - func[2165] <ka> -> "ka"
 - func[1487] <ma> -> "la"
 - func[1487] <ma> -> "ma"
 - func[2173] <na> -> "na"
 - func[2172] <oa> -> "oa"

[sbc100]

If you build with -sSTANDALONE_WASM those imports and exports will no be minified in that way.

[guest271314]

@sbc100 Any idea how I can create the .wasm file(s) with Emscripten without the JavaScript glue code; that is, where the glue code is .wasm, too, so I can do something like this with the .wasm file created by Static Hermes?

    const pluginInstance = await WebAssembly.instantiate(
      pluginModule,
      { "wasi_snapshot_preview1": wasi.exports },
    );
    const instance = await WebAssembly.instantiate(embeddedModule, {
      "javy_quickjs_provider_v3": pluginInstance.exports,
    });

    wasi.memory = pluginInstance.exports.memory;
    instance.exports._start();

[guest271314]

I already tried -sSTANDALONE_WASM, WASI-SDK's clang, and LLVM Project's clang. Neither of the 3 work with the .o and .c files that are produced by shermes.

[guest271314]

Pardon, produced by shermes and Emscripten's emcc, here https://github.com/facebook/hermes/blob/static_h/utils/wasm-compile.sh#L46-L63

echo "Using shermes to compile $input... to ${file_name}.c"
"$shermes" -Xenable-tdz -emit-c "$input"

echo "Using emcc to compile ${file_name}.c to ${file_name}.o"
emcc "${file_name}.c" -c \
    -O3 \
    -DNDEBUG \
    -fno-strict-aliasing -fno-strict-overflow \
    -I${wasm_build}/lib/config \
    -I${HermesSourcePath}/include

echo "Using emcc to link ${file_name}.o to ${file_name}-wasm.js/.wasm"
emcc -O3 ${file_name}.o -o ${file_name}-wasm.js \
    -L${wasm_build}/lib \
    -L${wasm_build}/jsi \
    -L${wasm_build}/tools/shermes \
    -lshermes_console_a -lhermesvm_a -ljsi \
    -sALLOW_MEMORY_GROWTH=1 -sSTACK_SIZE=256KB

I posted one of my attempts using LLVM's clang in OP.

I got wasm-ld errors when I used WASI-SDK's clang, before I was aware that -Wl,-rpath was specific to creating an ELF

wasm-ld: error: unknown argument: -rpath
wasm-ld: error: unknown argument: -rpath
wasm-ld: error: unknown argument: -rpath
wasm-ld: error: unable to find library -lshermes_console
wasm-ld: error: cannot open ./build_release/lib: Is a directory
wasm-ld: error: cannot open ./build_release/jsi: Is a directory
wasm-ld: error: cannot open ./build_release/tools/shermes: Is a directory
wasm-ld: error: unable to find library -lhermesvm
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[guest271314]

I'm basically trying to reproduce with Facebook's Static Hermes what I can do with Bytecode Alliance's Javy and then convert that WASM back to JavaScript with wasm2c, so the JavaScript is the ultimate source code, from which we can branch to native executable or WASM in the C format, and back to JavaScript in asm.js format.

That is, JavaScript manifested as a "universal" programming language and the capability to have "universal executable" using JavaScript as the source code.

import { readFile } from "node:fs/promises";
import process from "node:process";
import { WASI } from "./wasi-minimal-min.js"; // https://gitlab.com/-/snippets/4782260/raw/main/wasi-minimal.js
import * as fs from "node:fs";
try {
  const [embeddedModule, pluginModule] = await Promise.all([
    compileModule("./nm_javy_permutations.wasm"),
    compileModule("./plugin.wasm"),
  ]);
  const result = await runJavy(embeddedModule, pluginModule);
} catch (e) {
  process.stdout.write(e.message, "utf8");
} finally {
  process.exit();
}
async function compileModule(wasmPath) {
  const bytes = await readFile(new URL(wasmPath, import.meta.url));
  return WebAssembly.compile(bytes);
}
async function runJavy(embeddedModule, pluginModule) {
  try {
    let wasi = new WASI({
      env: {},
      args: [],
      fds: [
        {
          type: 2,
          handle: fs,
        },
        {
          type: 2,
          handle: fs,
        },
        {
          type: 2,
          handle: fs,
        },
      ],
    });

    const pluginInstance = await WebAssembly.instantiate(
      pluginModule,
      { "wasi_snapshot_preview1": wasi.exports },
    );
    const instance = await WebAssembly.instantiate(embeddedModule, {
      "javy_quickjs_provider_v3": pluginInstance.exports,
    });

    wasi.memory = pluginInstance.exports.memory;
    instance.exports._start();
    return;
  } catch (e) {
    if (e instanceof WebAssembly.RuntimeError) {
      if (e) {
        throw new Error(e);
      }
    }
    throw e;
  }
}

echo '4 5' | deno -A ../run-wasi.js
5 of 23 (0-indexed, factorial 24) => [0,3,2,1]

javy emit-plugin -o plugin.wasm
javy build -C dynamic -C plugin=plugin.wasm -o nm_javy_permutations.wasm nm_javy_test.js
echo '4 5' | wasmtime run --preload javy_quickjs_provider_v3=../plugin.wasm ../nm_javy_permutations.wasm
5 of 23 (0-indexed, factorial 24) => [0,3,2,1]

The fact that there's no application in the JavaScript/C/C++/WASM world that can convert to and fro - yet there are random Web sites that can convert JavaScript to C is an issue to me.

[guest271314]

There's still no guidance on how to convert the WASM and to C from wasm2c to an executable, yet WebAssembly/wabt#2521.

[guest271314]

So with Javy we get JavaScript to WASM, with the WASI reactor. With Static Hermes we get JavaScript to C, without the WASI reactor.

This should be possible JavaScript <= C => WASM | Native executable <=> JavaScript.