As a firefox/electrolysis developer, I recently hit a little snag with some harder-than-usual part of the code. I had written a code patch for it, and found very difficult to see the associated effects of my patch compared to the expected non-patched results. Dual-debugging was really indicated here and I therefore spent some time formalizing a win32 dual-debugging method of my own to increase my efficiency.
But first, what’s dual-debugging ?
“Dual-debugging” simply means debugging two versions of the same application *at the same time* (usually a patched and a non-patched versions). The major advantage is that it lets you easily see the tiny differences that your patch brought up (by stepping through the code on both debuggers). The main drawback is that this method requires more ressources from your system (usually two codebases and two profiles).
I’m developing on Windows with the very stable and mighty Microsoft Visual Studio 2008. The following is a step-by-step tutorial explaining how you can easily setup a dual-debugging environment. I’ll take “electrolysis” as an example, but you can apply those principles to almost any other application.
dual-debugging HOWTO :
1. Duplicate your working tree
To trace into your code on both debugguers, you’ll have to duplicate your code directory in a similar, parallel location. For example, let’s say your code is located under :
let’s just copy the whole “codebase” directory to this new location
2. Duplicate your MSVC projects and solutions
Same thing here. Your MSVC project files contain important information about sources files that are going to be debuggued. You must duplicate all the *.sln and *.vcproj. For example :
D:\WORK\MSVC\*.* --> D:\WORK2\MSVC\*.*
3. Duplicate your profile for the debuggued application
Many applications use user preferences for various runtime checks. One of those is to make sure the application is not already instanciated when you run it. This is the case with firefox and electrolysis. If you keep a single user profile, you won’t be able to debug two instances of it in parallel because it’ll say : “Firefox is already running in the background…” To solve this problem, just create another profile. For firefox, or electrolysis, this is easily done by :
./firefox -P dummy
Using the little firefox profile GUI, create another profile with a different name.
Then run the application once with the newly created profile. For electrolysis, with a newly created profile called “electrolysis2”, do the following :
./firefox -no-remote -P electrolysis2 -chrome chrome://global/content/test-ipc.xul
4. Modify the duplicates properly
Now, you have to make all the duplicated projects and code files point to the new directories and duplicated files.
- With MSVC’s “Find and Replace In Files” dialog (CTRL-SHIFT-H), change every “\WORK\” by “\WORK2\” …
- For the duplicated working tree directory.
- For the duplicated MSVC project directory
- In MSVC, change the debugging command arguments to use the newly created profile. For example, if debugging electrolysis, do :
- Open the duplicated solution (.sln)
- Right-Click on the startup project’s “properties” pop-up menu item
- In the “Debugging” menu item, under “Configuration Properties”, change “-P electrolysis” for “-P electrolysis2”.