Debugging Rust with Miri

There's very mature tooling for debugging binaries, but the tooling for using miri as a debugger doesn't exist. This is the core reason.

However, I think a more productive way to frame this is "why has nobody created one of these yet," which is what I think you mean when asking this. I suspect a few reasons:

Existing debugging tooling is good enough. To be honest, I only use a debugger with Rust when doing embedded work. However, I will state that this is not universally true; my employer has developed a debugger, and we still rely on debugging the binary rather than an interpreter.

Why is that the case? Well, for one, miri cannot run all programs, notably, (from its readme) "Miri runs the program as a platform-independent interpreter, so the program has no access to most platform-specific APIs or FFI." This is a huge limitation for the debugger use-case, often which is needed expressly around code with platform-specific APIs. And, okay, let's imagine that there's a fix for this that lets you call into them. That's great, but since our debugger is based on interpreting Rust code... it would not be able to follow things through that layer into the underlying FFI call. Binary debuggers can.

Miri is significantly slower than real Rust code. This is for an extremely good reason: it's doing a ton of work that wouldn't be done in real code. It also is based on the code before it undergoes many of the optimizations that Rust programmers rely on to compile away layers of abstraction and get reasonable performance, as those happen in LLVM. Some "mir-opt" passes exist, IIRC, but are experimental, and certainly don't cover all of what LLVM does. Why might that matter for a debugger? Well sometimes the thing you're trying to debug is performance sensitive. If Miri can't execute your program in a reasonable time, debugging it will be difficult if not impossible. Especially if you're trying to debug something like a race condition; the slowness of said debugger may hide the race.

That's just some thoughts off the top of my head. There may be other reasons too, and this doesn't mean Miri will never possibly be good for this use case, but I don't think the team is really trying to do that, so someone would have to want to do that and want to put in the work, and it probably would need to not interfere with the main goals of miri. That's a lot of ifs.