When I was debugging MIPS64 JIT backend, I noticed that we don't have a working disassembler for MIPS (Loong64 as well).

Instead of introduce another in-house disassembler implementation, I think it might be better to introduce capstone (http://www.capstone-engine.org/) as a generic disassembler solution and wire it up for MIPS & Loong64.

If it's proven to be successful, we can even migrate other architectures to capstone.

I would like to seek comments from the community about this move. If people think that's the right direction to go, I'll propose an initial implementation for review.

Thanks

Thanks for filing this. I like the idea of unifying our disassemblers. Capstone has the BSD license so that part works for us.

We currently use Zydis for x86/x64 in JS_JITSPEW builds and we should replace it at the same time.

My main concerns are:

• Compilation time, because people do a lot of JS shell debug builds. It's all C code so I assume it's pretty fast though and in COMPILE.TXT they mention it's possible to compile only a subset of all supported architectures, but worth checking.
• Is it easy to integrate with our build system?

Let's wait a few days to see what other people think.

(In reply to Jan de Mooij [:jandem] from comment #1)

Thanks for filing this. I like the idea of unifying our disassemblers. Capstone has the BSD license so that part works for us.

Thanks for your input! Regarding those two concerns:

We currently use Zydis for x86/x64 in JS_JITSPEW builds and we should replace it at the same time.

My main concerns are:

• Compilation time, because people do a lot of JS shell debug builds. It's all C code so I assume it's pretty fast though and in COMPILE.TXT they mention it's possible to compile only a subset of all supported architectures, but worth checking.

A single arch (MIPS64) build took around 1 min on my laptop, I think that's acceptable for this case.

• Is it easy to integrate with our build system?

I've done a PoC and despite ugly CXXFLAGS required to disable clang warnings, I see no difficulty so far.

I'm not really sure how should we track upstream update though, should wem just import source like what
we've done to Zydis or use updatebot?

Let's wait a few days to see what other people think.

Thanks!

If we do this, we'll need to replace Zydis at the same time, to avoid having to maintain two separate disassembler libraries.

(In reply to Jiaxun Yang [:flygoat] from comment #2)

A single arch (MIPS64) build took around 1 min on my laptop, I think that's acceptable for this case.

One minute is quite a lot to add to a JS shell build. It should have compile times roughly similar to what we have now with Zydis. A little more is acceptable but not much more.

Ryan, do you have any thoughts on this? I'm asking because you've updated Zydis before.

302 :rhunt

An extra minute of compile time seems high to me as well. I think we only build these in debug builds? So maybe that mitigates it a bit.

For the wasm team, our main use of the disassemblers (outside of inspecting code every once in a while) is for 'codegen' tests (two random examples: [1] [2]). Another requirement here would be that capstone ideally doesn't require us to significantly rewrite these tests. Some small formatting changes would be fine.

I also believe our ARM32 (and maybe other disassemblers) has some support for recognizing the constant pools we generate [3]. It'd also be nice to not regress that.

[1] https://searchfox.org/mozilla-central/rev/527d691a542ccc0f333e36689bd665cb000360b2/js/src/jit-test/tests/wasm/bce-x86-ion-codegen.js#16
[2] https://searchfox.org/mozilla-central/rev/527d691a542ccc0f333e36689bd665cb000360b2/js/src/jit-test/tests/wasm/binop-arm64-ion-codegen.js#19
[3] https://searchfox.org/mozilla-central/rev/527d691a542ccc0f333e36689bd665cb000360b2/js/src/jit/arm/disasm/Disasm-arm.cpp#1925