I've always had the attitude that if can reproduce a bug consistently, I can debug it, and I can fix it. Now here's a nail in the coffin of that theory.
Only if the problem is purely software. I've had reproducible problems that were impossible to solve by myself. The process went like this:
- Huh, getting USB disconnects randomly, need to fix this
- Hmm, device driver seems to be fine
- Hmm usbnet driver seems fine
- Hmm xhci driver seem fine
- $5000 and one USB 3.0 protocol analyzer later...
- What the heck is this host controller doing?
At this point it was looking like a hardware problem but seeing as I didn't have the schematics or verilog of the host controller I could go no further (nor did I want too... I never imagined USB could be such a deep rabbit hole).
Most of the bugs I've dealt with, the problem was usually down to something simple that can be explained quickly. (e.g. syntactically valid typo, config error, simple logic error etc.).
Seems like "Holy grail" bugs like this happen to need a thorough understanding of complex systems (which I usually like to hide under layers of abstraction).
In defense of the coffin, I'd say this is not so much about a bug, but about reverse engineering real world effects of undefined behavior (as caused by a bug in software).
That is not the goal of mGBA (or any GBA emulator for that matter), btw. If you wanted to reproduce it faithfully, the emulator would be unusably slow.
You are trying to argue about the meaning of the words being used. This is not productive, as what matters is what the author of the argument meant when they used that word.
To be honest, I think it's about crossing the lines of emulation and simulation. In emulation, we mostly consider instruction level behavior as good enough, but here, we'll have to venture below cycle level and integrated hardware effects to copy the behavior.
