ADVERTISEMENT

Volume Number: 13
Issue Number: 2
Column Tag: From The Factory Floor

Mike Lockwood, Debugger

By Dave Mark, ©1996 by Metrowerks, Inc., all rights reserved.

One of the most important, yet least understood part of the Mac development process is the debugger. Sure, everyone knows how to use the debugger to step through your source code, but I've always wanted a peek beneath the hood, a chance to see how a debugger really works. This month's interview is with Mike Lockwood, debugger extraordinaire.

Dave: You worked at Apple four years before you came to Metrowerks. What did you do there?

Mike: I first started working on development tools on my own, before I joined Apple. I wrote my own MacApp debugger as a side project, and when I got it working I sold it to Apple. Apple contracted me to finish it, and it shipped on E.T.O. as SourceBug. Soon after that, I joined Apple as an employee and worked for a year on the debugger for a new integrated development environment that was to replace MPW.

After that project was canceled, I transferred to the System Software group and worked on the Finder team. At the time there was no source level debugger that could debug Finder extensions, so I kept working on the debugger from my previous project - so I could use it myself. I added support for debugging threads and shared libraries, and it was soon being used by a number of different groups within Apple. Since it was an underground, guerrilla programming effort, I decided to call it VoodooMonkey. Then when no one was looking, someone snuck it on one of the Developer CDs and VoodooMonkey shipped outside of the company. Since then, it became somewhat of a cult classic.

After working on the Finder team for awhile, I became interested in working on developer tools again and wanted to move back to the East coast. So I transferred to the Cambridge office to work on the Dylan project. There, I wrote the application framework for Apple Dylan, and served as the main guinea pig for the Dylan compiler and development environment. After that project got canceled, there was an opportunity for me at Metrowerks, and I joined them the day after I left Apple.

Dave: How did you hook up with Metrowerks?

Mike: Metrowerks first contacted me in the Fall of 1993. They needed a 68K debugger nub for CodeWarrior, Apple only had a PowerPC version of DebugServices up and running. Greg Galanos called me to see if he could use DebuggerINIT, which was the debugger nub I wrote for VoodooMonkey. At the time, I didn't know much at all about Metrowerks, other than they were working on a C/C++ compiler for PowerPC. I wanted to help them out, but I also wanted to avoid some of the political problems I ran into after VoodooMonkey shipped. So, I directed Greg to go through the proper channels in Cupertino.

I knew Greg would never be able to cut through all of the red tape, and I wasn't sure I would ever hear from him again. However, he called me two days later and said "Hey, I just licensed the sources to DebuggerINIT from Apple." Now I knew I was dealing with a force to be reckoned with.

I continued to talk to Greg and other people at Metrowerks, and provided some informal tech support for DebuggerINIT. When it was clear that the Dylan project was going to be shut down, I talked more seriously with Metrowerks about joining the company. Dan Podwall, the original author of the Metrowerks debugger, was busy working on the browser and they needed someone to take over the debugger.

Dave: What exactly is a debugger nub?

Mike: A debugger nub is a small program that controls a program that is being debugged, and is responsible for things like setting breakpoints and single stepping through code. It provides a layer between the main debugger application and the low level system stuff. The distinction is important in the case of two machine debugging, because the debugger nub runs on the machine being debugged and the debugger application runs on a different machine. MetroNub is our debugger nub for single machine MacOS and Java debugging. We have other debugger nubs for debugging code running on other platforms.

Dave: How does MetroNub interface with the Metrowerks debugger?

Mike: MetroNub is a system extension that provides an API to the Metrowerks debugger that supports debugging functionality like single stepping. MetroNub exports a structure full of mixed mode function pointers via a Gestalt selector that the debugger application can call. MetroNub also interfaces with various parts of the OS. For example, it patches the Resource Manager to track where code resources are loaded in memory, and uses an undocumented Process Manager API to suspend and resume a process that is being debugged. It also patches the 68K exception vectors and registers callback functions with the PowerPC Exception Manager and the MP kernel so it can be notified when exceptions occur.

Now let's examine what happens when you single step through a line of code. At this point, the program is already stopped, meaning that MetroNub had already told the Process Manager to suspend the program's process and make it ineligible for scheduling. The debugger application then calls the MetroNub "Step" command. When it makes this call, it would specify to MetroNub whether to step into or step over function calls. It would also specify a range of addresses for the program counter so MetroNub will not stop execution again until the PC is outside of this range. When stepping though source code, this range would correspond to a single line in the source code.

MetroNub would record the PC range specified, and would then tell the Process Manager to resume the process. The process is then eligible to be scheduled again, but will not actually resume until the debugger application calls WaitNextEvent(). After it is rescheduled, some of MetroNub's code that was left on the call chain of the program being debugged will resume execution. Before MetroNub returns control to the program being debugged it restores all the registers and sets the trace bit in the processor's status register. The trace bit tells the processor to cause a trace exception after each instruction is executed. MetroNub receives these trace exceptions, and processes them until the program counter falls out of the specified range. Then MetroNub tells the Process Manager to do an immediate context switch from the program being debugged to the debugger application. This leaves some of MetroNub's exception handling code on the call chain of the program being debugged, which will resume after the program being debugged is rescheduled by the Process Manager.

Dave: What language is MetroNub written in?

Mike: MetroNub is written almost entirely in C++, with just a small amount of 68K assembler. The assembler is used only in a few places where it is necessary to access registers directly or execute some uncommon 68K instructions. For example, the 68K exception vector patches and some of the Resource Manager patches are written in assembler. MetroNub is mostly 68K code, and only contains a small amount of PowerPC glue code for some of the callbacks it registers with the OS.

Dave: But how does the link between the source code MetroNub happen?

Mike: MetroNub doesn't know anything about the source code. The debugger application handles the mapping from source code to object code offsets, based on information in the sym file, which is generated by the compiler and linker. Suppose you want to set a breakpoint at a certain line of source code. The sym file contains a table that maps the offset in the source file to an offset in the object code for the function containing that line of code. A different table in the sym file is then used to translate the offset in the function's object code to an offset into a CFM code fragment or a code resource. The debugger then tells MetroNub to set a breakpoint at the given offset within the code fragment or code resource.

The debugger application does not have to know where the code is loaded in memory or if it is even in memory at the time the user sets the breakpoint. If it is loaded, the debugger will convert the offset to an absolute address and insert a trap instruction at the address where the breakpoint should be set. If the code is not loaded yet, MetroNub remembers the breakpoint and installs the trap instruction after the code is loaded but before the program is able to execute the code.

Dave: What changes did you have to make to your design to deal with Java?

Mike: Fortunately, no major design changes were needed to support Java. That was good news for us, because time-to-market was important. Our debugger could already debug two different processor architectures (68K and PowerPC) simultaneously, so adding a third architecture was not difficult. We just treated Java byte codes as if they were assembler instructions and the Java VM as if it was a microprocessor, and the debugger architecture we already had in place worked fine. I had to write a new implementation of the symbolics code so it could read symbolic information from Java class files and Zip files instead of a sym file. I also had to add an API to the Metrowerks Java VM so MetroNub could communicate with the Java VM and control the execution of Java code. This approach had the nice side effect that it is possible to debug both 68K and PowerPC C/C++ code and Java code simultaneously with a single debugger.

Dave: A lot of companies have said that they will no longer support the 68K. Do you think learning to debug 68K code is a worthwhile investment?

Mike: 68K is becoming less important, but a good understanding of 68K code is valuable when debugging on System 7, even if you are writing PowerPC native code. Since much of the operating system is still emulated 68K code, it is not uncommon to have to debug 68K code on a PowerMac.

Dave: What's your feeling on how people should approach debugging? Should they learn MacsBug? Should they buy a copy of Jasik's Debugger? Learn PowerPC assembler? Got any good book recommendations? Are there utilities people should definitely have on their hard drive?

Mike: The Metrowerks debugger is strictly a high level debugger. You also need to have a low level debugger like MacsBug or Jasik's debugger installed when debugging with the Metrowerks debugger. Jasik's debugger is actually both a low level and high level debugger, so if you like Jasik's debugger, you don't even need a copy of the Metrowerks debugger! Jasik's debugger is very powerful and has a lot of features that no other debugger has. But many people find the Metrowerks debugger easier to use.

Nowadays, it isn't critical that you learn PowerPC assembler, unless you need to write very low level or very optimized code. But for debugging purposes, it is often useful to have basic reading knowledge of assembler, even if you do not write it yourself (I have written a lot of 68K assembler over the years, but haven't actually had a need to write any PowerPC assembler yet). But understanding how to read and debug at the assembler level can be very useful at times.

There are a number of utilities available that can help you with debugging. You can use the Debugging Memory Manager from Apple to help catch memory problems in your application heap. Similarly, you can use the DebugNew library that comes with CodeWarrior to track down memory problems in the built-in C/C++ memory allocater. Zone Ranger, which also comes with CodeWarrior, can be helpful monitoring memory usage and watching for memory leaks. There are a number of extensions, like EvenBetterBusError, DoubleDispose, etc. that are available from Apple that watch out for common programming errors when using the Memory Manager or Resource Manager. Onyx Technology has a tool called QC that monitors all Memory Manager calls and checks for these programming errors. A demo version of QC is available on the CodeWarrior Reference CD.