Challenge 2: #debugging. You spend a ton of time writing the compiler, fingers crossed for getting at least the hello world working, but instead you get table/memory out of bounds! Unreachable instruction executed! What on earth went wrong!?? It's totally not a shame to not get things right on the first try. Especially compilers, one small mistake may be amplified repeatedly at compile-time, making the output a pile of trash.

But you're unlucky if targetting #wasm. You may have searched the internet and found blog posts about source maps, dwarf, v8 inspector, or some wasm engine claiming to support debugging via lldb/gdb. My own experience as of today: they are extremely fragile if not to say non-existent. Give them a try anyway, but keep in mind they don't qualify as your lifeboat, and to get dwarf stuff working you need a ton of extra effort during code generation!

There're still some strategies you can follow.

First and foremost: crash early. Instrument your code aggressively, whenever you doubt if a property holds at runtime, assert it. It's common that the runtime state is already corrupt but the module runs longer and trips on other seemingly irrelevant places. You may also dump logs, they do help sometimes.

Next: shrink it. Use wasm-reduce in #binaryen to shrink the wasm module, or even better, use #creduce to shrink the miscompiled module's assembly source (if you know it's the crime scene), or the offending input that triggers the bug. Shrinking is an absolute must to minimize the debugging overhead. In the worst case you don't get additional insight, but at least you get some coffee breaks to relax :/

Sometimes you have an alternative compiler which emits correct wasm from the same input, which can be regarded as the source of truth. Luckily this was the case for #ghc wasm backend! GHC has target-specific assembly generators, but also a target-independent c generator, which is meant to ease porting GHC to new platforms. And it was tremendously useful when I debugged the wasm backend's code generator part; I even spent extra effort to make callconv & symbol names coherent between the two codegens, mixed good/bad objects at link-time, this was super useful when narrowing down the actual crime scenes.

Another low effort thing to try, especially if your compiler piggybacks on other toolchains like #llvm or binaryen: turn off any optimization. If you're lucky, it's someone else's bug :)

#CReduce is an impressive piece of software. If you're not familiar with it: you give it a C file that exhibits a bug, or some other interesting property (you specify a shell script that returns 0 only if the file is interesting). It then proceeds to shorten the file considerably.

I had a 10 kLOC file on which my analyzer showed buggy behaviour, CReduce shrinked it by 99.6 % 😅 (so far)