Debugging potential JIT issues

[sjamesr]

My team is experimenting with WAMR fastjit on x86. We have an internal benchmark that runs successfully in interpreted mode, but crashes with an operand stack overflow in fastjit mode. We're trying to assemble a minimal example that demonstrates the issue, but in the meantime, are there best practices/techniques that the WAMR devs use to debug potential JIT issues? For example, I'd like to be able to dump the JIT-generated code corresponding to our failing function.

[TianlongLiang]

Hi, you can add more operand stack sizes by passing a desirable size to iwasm like: iwasm --stack-size=n, it's worth a try, maybe it can solve your crash issue

For general Fast Jit debugging, you can refer to this issue and use the method this author adopted.
Basically, you can dump the jitted code(by default only dump the fast jit IR) through this process:

1. In core/config.h, change #define WASM_ORC_JIT_BACKEND_THREAD_NUM 4 to 1, so that the dump won't be out of order.
2. (optional) If you want to dump the native code, change the #define CODEGEN_DUMP 0 to 1 in jit_codegen_x86_64.cpp
3. compile the iwasm with -DWAMR_BUILD_FAST_JIT_DUMP=1