I am using the Virtual Machine Manager (virt-manager) on the Ubuntu distro. The documentation is sparse regarding the setup with debian-9 guest systems (systemd based) using the virt-builder but with ‘none’ graphics support. Most blogs refer to ‘adding kernel parameters to /etc/inittab’ but this SYSV-config-file does not exist any longer since transition to systemd. It is required to set kernel parameter  that redirect  console IO  to  ttyS0.  With systemd this can be  achieved defining grub-default-parameters in file /etc/default/grub and re-creating the grub-menu-config.

Building the image:

sudo virt-builder debian-9 -v -x -o my-image.qcow2 --hostname dnssv.intern --root-password password:root --install "bind9,bind9-doc,dnsutils" --edit '/etc/default/keyboard: s/^XKBLAYOUT=.*/XKBLAYOUT="de"/' --edit '/etc/default/grub: s/^GRUB_CMDLINE_LINUX_DEFAULT=.*/GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0"/' --run-command '/usr/sbin/update-grub2'

Installing into virtual machine manager:

virt-install --name dnssrv --ram 256 --disk path=my-image.qcow2,format=qcow2 --import --graphics none

Instead of graphical windows with scaled fonts, on startup you should see a simple text console.

The tooling is available installing the following debian packages
sudo apt-get install libguestfs-tools
sudo apt-get install virt-manager


My intention was to analyze, how C-pointer-arithmetic are translated to WASM code. Assuming you have got the a  C++ file foo.cpp like:

/// @file foo.cpp
#include <emscripten.h> // macro EMSCRIPTEN_KEEPALIVE
#include <stdint.h>

extern "C" {
void EMSCRIPTEN_KEEPALIVE myfunction(uint8_t *dst, uint8_t *src) {
 dst[0] = src[0];
 dst[1] = src[1];
}
} // extern "C"

The following code will produce  the output file foo.wasm wiht the the corresponding WASM code (file size arond 255 bytes):

emcc foo.cpp -v -O3 -s ONLY_MY_CODE=1 -s WASM=1 -s SIDE_MODULE=1 -o foo.wasm

Check the content of this file using the disassembler tool wasm-dis form project binaryen:

wasm-dis foo.wasm

The output of the disassembler looks like:

(module
 (type $0 (func (param i32 i32)))
 (type $1 (func))
 (import "env" "memoryBase" (global $import$0 i32))
 (import "env" "memory" (memory $0 256))
 (import "env" "table" (table 0 anyfunc))
 (import "env" "tableBase" (global $import$3 i32))
 (global $global$0 (mut i32) (i32.const 0))
 (global $global$1 (mut i32) (i32.const 0))
 (export "_myfunction" (func $0))
 (export "__post_instantiate" (func $2))
 (export "runPostSets" (func $1))
 (func $0 (type $0) (param $var$0 i32) (param $var$1 i32)
 (block $label$0
 (i32.store8
 (get_local $var$0)
 (i32.load8_s
 (get_local $var$1)
 )
 )
 (i32.store8 offset=1
 (get_local $var$0)
 (i32.load8_s offset=1
 (get_local $var$1)
 )
 )
 )
 )
 (func $1 (type $1)
 (nop)
 )
 (func $2 (type $1)
 (block $label$0
 (set_global $global$0
 (get_global $import$0)
 )
 (set_global $global$1
 (i32.add
 (get_global $global$0)
 (i32.const 5242880)
 )
 )
 (call $1)
 )
 )
 ;; custom section "dylink", size 5
)

The disassembled code shows, that no dependencies to JS or other runtimes exists. Still a number of functions can be identified in the  import and export section,  “myfunction” does not depend on actually.

Note: Just in case, please let me know how to eliminate the imports of “memoryBase”, “memory”, “table”, “tableBase”, and eliminating the exports of  “__post_instantiate”, “runPostSets”.

The following code shows the disassembled operations of ‘myfunction’ (function $0).  AFAICS, the pointer parameters are of type i32, and the index is translated to a bytewise store8/load8 using the offset feature, for example ‘offset=1’.

(func $0 (type $0) (param $var$0 i32) (param $var$1 i32)
 (block $label$0
 (i32.store8
 (get_local $var$0)
 (i32.load8_s
 (get_local $var$1)
 )
 )
 (i32.store8 offset=1
 (get_local $var$0)
 (i32.load8_s offset=1
 (get_local $var$1)
 )
 )
 )
 )

Switching back from google blog back to wordpress