Debugging Techniques

[ShizZy]

Howdy - I have a couple of questions for my fellow emu coders. One of my weakest skills is in the area of debugging, so I've been somewhat studying it latelly. From what I've gathered, here are the basic debugging methods:

-the "fine needle" method, going over your code line by line and reading available documents, checking that you are handling everything properly. This is by far the most redundent method, but it is bound to work. The only problem is if you're looking for bugs by reading code, and you're not quite sure how something works, you won't spot a bug.

-Tracing - taking your emu and comparing registers step by step with a proven emulator. This works well, until you get into all sorts of memory reads and writes and there's more to bugs that just opcode register manipulation. Also, it's somewhat tedious to trace with another emu when your first 5mb of instructions are corrected, going through them without overlooking a mistake yourself is very difficult.

-Reverse Fixing - running a rom that you know inside-out (preferably one that you made), so you know exactly how your emulator should be handling it. Then you know exactly what to check when something isn't right. Often combined with the trace method. Drawbacks are it'll require you to learn how to program for the system as well, which is more time consuming, but not a bad thing.

My question is - how do you guys go about debugging your emulators, especially those of you who have finished emulators? I'm going to need to grasp these concepts and techniques if I ever hope to finish mine. If you use a method similiar to these, can you describe in detail how you go about doing it? Big thanks

 

[zilmar]

An interrupter is easier to debug then a recompiler, at the moment I am going to assume your debugging an interrupter. If you have another working emu, then life is easier, comparing step by step is a lot of work and slow but will get the answer. If I can compare tho, I will compare at jumps and see we take different code paths. This will give you an idea where a register is different, then trace back where that is set, and stored. Manually go through every op at times, might come to the only answer, but I think you did cover most of the answers there.

With pj64 originally I worked on simple demos, and slowly added more roms that did something different. If you got some working ones and non working ones. What are different (eg one calls certain ops and another one doesn’t), track how they use special registers. It really depends on the bug and what the effect it is showing.

 

[ShizZy]

zilmar, big thanks for your input. That is correct, I am debugging an interpreter. Another method is to just guess where the emulator is going wrong based off of results, and then checking and double checking that part of the hardware emulation. But that usually requires you to have something already working well enough to understand it, and also for you to know how the hardware reacts to different issues.

Anybody else?

 

[Cyberman]

Hmmm
First you should comment your code coopiously. I make lots of comments on my code these days in case someone has to pick up where I left off. IE code with the idea someone else may be reading it. Do NOT pick stupid variables IE thingy_that_keeps_track_of_stuff doesn't work very well

variable names such as
timer_system_interrupt_control is good.
Always make variable names that can be easily understood what they are for. You do not need to make long variable names, just ones that are consistant and MATCH what you have named everything else.
If you use Macros ALWAYS captalize the entire macro name (so it's known it's a macro). Function names should use capitalization to break up expressiveness. IE

// ExecOpCodePrefix_CB
// performs CB prefix opcodes for the Game Boy Sharp
// Z80 like processor
// Returns: Nothing
// Passed: OpCode prefixed by 0xCB
void CpuThread::ExecOpCodeExtension_CB(UINT8 OpCode)
{
   // ... Code goes here
}

Is a reasonable example of what I'm talking about.

This makes debugging MUCH easier. Another thing is to have a PEER review of the code, if there is a bug you can't seem to find. Ask someone who codes all the time to review the section of code you think the bug is in. I suggest also being sure you aren't doing anything obviously stupid. Have a POA for your program available as well (Plan Of Action), this shows how it's supposed to work .. then check if this matches available documentation. The majority of bugs are caused by typos not caught by the compilor or other simple typing mistakes. Look for obvious mistakes first.

Next you should look for functional mistakes IE how should this work, how is it working and does it make sense how I'm doing it. If it seems a confused bit of spagheti you should rewrite it. Don't be afraid to throw out entire chunks of code, I do it all the time

After these steps your bug is more likely to just never happen to begin with.
Jack Ganssle's web site is an excelent places to look for how to make code more reliable and avoid time consuming mistakes. There are a lot of tips on that site.. you should read most of them too.
Cyb

 

[ShizZy]

Thanks Cyb. Really useful stuff.

Anyone else have any comments? I'm really interested in the actual steps that people take when they try and solve an unknown bug. I realize that these do vary, and can get complex at times, but I'm sure we all have our basic debugging routines that we frequently use.