Volume Number: 15 (1999)
Issue Number: 8
Column Tag: From the Factory Floor

Richard Atwell, Mac OS Debugger

by Richard Atwell and Dave Mark, ©1999 by Metrowerks, Inc., all rights reserved.

This month, we'll hear from Richard Atwell, a key member of Metrowerks' Debugger team. Richard will fill us in on the latest and greatest in Macintosh CodeWarrior debugging.

Richard Alexander David Atwell, aka ratwell, is the Mac OS Debugger Engineer at Metrowerks and is responsible for making MetroNub do nasty things to Mac OS so you can debug your code. Before joining Metrowerks, Richard worked for the Apple Education Consultant Program in Canada. He can be reached at <ratwell@metrowerks.com>.

Dave: Richard, tell me about your role at Metrowerks?

Richard: I work on Mac OS Debugging along with Ken Ryall, our Debugger Architect and our Java debugger engineers. Ken and I are responsible for adding support in CodeWarrior's integrated debugger for emerging Mac OS technologies.

Dave: I know you are working on the debugger for Mac OS X. Tell me about that.

Richard: CodeWarrior runs on Mac OS, Windows, Solaris and now Linux. Before we could deliver a version that ran on Mac OS X, developers needed to be able to debug applications that ran on the new operating system. At the time, the only remote debugger that we had was the Mac->Win debugger that lets you debug targets that run on a Win32 machine from a Mac running the IDE, but there wasn't much that we could reuse for the new OS. So with help from Apple we decided to leverage the debugger built into Mac OS X called gdb.

gdb is the command line debugging tool that is indigenous to UNIX based operating systems like Mac OS X. We discovered that NeXT/Apple had been modifying gdb over the years to meet their own needs but had kept it up to date with the open-source gdb version. All that we needed to do was hide the gdb command line interface from the developer and allow it to be controlled from the IDE.

With Apple's assistance we created a remote debugger for CodeWarrior running on Mac OS 8 that allows you to debug applications on a second Mac running Mac OS X over TCP/IP. gdb is running behind the scenes on Mac OS X but all the developer sees is a simple control panel like application that allows you to set the IP address and port of the machine that is running the IDE and a button to start/stop gdb.

Dave: Tell me about the new Mac OS 8 remote debugger? Is it similar to what Metrowerks did with the Mac->Win cross debugger?

Richard: Yes. For Windows we have an application called MWRemote that is run on the target machine and it acts as the middleman between the IDE running on the host Mac and Windows where your target runs.

For Mac->Mac debugging, we needed to write a similar application to run on the target machine. On the Pro 5 Tools CD in the "Other Metrowerks Tools" folder you'll find an application called MetroNub Remote 2.0. By running this application on a second Mac that has the MetroNub extension installed, you can debug applications remotely.

To operate it, run MetroNub Remote 2.0 and configure it with an IP address and port. This is a necessary security precaution to prevent "unfriendly" IDEs from debugging and essentially running programs on your Mac. Once the remote machine is setup, you configure the IDE for remote debugging by entering an IP address and port in the MetroNub settings preference panel. You next specify the path on the remote machine where the target is to be executed from and you're ready to debug the application just as you would if it were running on the same machine as the IDE.

Dave: What's new with Pro 5's integrated debugger?

Richard: We've added a lot of value to the debugger with Pro 5. The debugger in the IDE has an improved variables view that is better at displaying variable values for the supported languages. There is also a new widget at the top that toggles between two new variable modes: All and Auto. When the widget is toggled from All to Auto the view displays only the variables that are in the scope of the statement block where the program counter lies. Before we added this it was often awkward having to scroll the view down to the bottom to see the variables that you were interested in.

Remote debugging support for Mac OS 8 and Mac OS X is a large addition as we've already mentioned. Remote debugging is advantageous when you are short of screen real estate, wish to debug a system version earlier than the one you usually develop on, debug on another OS, or simply wish to stay independent of the program crashes that can interrupt your development cycle.

Dave: How about remote Java debugging?

Richard: Remote debugging of Java is now possible with Pro 5. In previous releases the MetroNub plug-in was used to debug Mac OS and Java programs. With Pro 5 our Java engineers have created a new debugger plug-in called SunJavaPlugin which uses the debugging facilities built-into Apple's MRJ. Debugging is done over TCP/IP when debugging on a local machine so making it work in the remote case required little extra development effort.

Dave: Is it possible to debug Java on other platforms?

Richard: Yes. Any Java VM that supports Sun's debugger API can be debugged remotely as long as both machines have TCP/IP services. We've also implemented a remote debugger for Win32 that lets you debug from one Win32 machine to another for the first time.

Dave: Aside from remote debugging, what else is new?

Richard: There is now an ability to control whether or not to attempt to automatically debug libraries that your program links against. There is a global setting for this that is used when there isn't a target, such as when you attach to an already running process. There is also a target-level setting to control this behavior.

We've changed the Debugger Setting panel that appears when you edit the preferences of your target. The field which previously specified the location of the host application has been changed to include the location of the remote folder where targets will execute from and also to include the location where code resources, shared libraries or DLLs that are used by your target can be found. The host application field has been relocated to a new panel called Runtime Settings.

We've also improved the reporting of libraries that are loaded by your application. You can now toggle whether the display of library loading messages appear in the log window with a checkbox. Previously this checkbox only applied if you were using the Mac->Win cross debugger.

To improve the debugging experience, there we've added a setting for a delay that can be adjusted which tells the IDE how often to refresh the contents of windows while you are debugging. This can also be set in the Debugger Settings panel.

Dave: How about Mac OS X and Carbon?

Richard: Mac OS X and Carbon are the hot programming topics today. Mac OS X has been making small leaps for about a year now and we've been making similar progress in order to keep from developing solutions with a short life span.

Our ultimate goal is to provide a Carbonized IDE that runs on the client version of Mac OS X. In the meantime we've been providing tools in staged releases.

Dave: What's been done for Carbon developers?

Richard: Carbon is Apple's programming model for Mac OS 8 and Mac OS X that allows developers to leverage the Mac OS toolbox based code they have developed over the last several years. Carbon is the only programming model on Mac OS X that doesn't require developers to completely rewrite their code. This makes Carbon very attractive to developers and we believe that CodeWarrior users are going to choose this development path over the others for most of their development needs.

Towards filling this demand we've been creating the tools that our customers require as the evolving Mac OS X technology allows us.

The first step we took was to release compiler and linker plug-ins with Pro 4 that created binaries in the Mac OS X native Mach-O execution. You could use these to create a separate target in your project that generated a Mach-O binary with which you could move over to Mac OS X and then debug it using gdb.

With the release of Mac OS X PR1 at WWDC this year, Pro 5 took the next logical step and made it possible to use the CodeWarrior integrated debugger for debugging applications on Mac OS X via remote debugging.

The Mac OS X remote debugger setup was specifically designed for debugging Carbon applications. Carbon applications can be PEF based just as they are now for Mac OS 8 or Mach-O based for Mac OS X. If you make applications that are PEF based using the Mac OS PPC Linker instead of the Mach-O linker, you can develop using a single target that you can then debug on Mac OS 8 or remotely on Mac OS X or Mac OS 8. If you app uses shared libraries for plug-ins or for code separation you'll have stick with PEF because Mach-O uses a different scheme for shared libraries that isn't supported by our debugger.

Dave: What's the word on AltiVec support?

Richard: AltiVec is an extension to the PowerPC architecture that provides 32 new 128-bit registers, 162 new instructions and a new execution unit within the AltiVec processor itself to complement the Branch, Integer and Floating Point units.

In addition, Apple and Motorola have introduced an AltiVec programming model for Mac developers in the form of an extension to the C language to support a new variable type called vector.

We've added the language support to our C/C++ compilers and added the necessary ABI changes to the linker. To the debugger, we've added support for displaying vectors variables just as we display any other type and we've added a third register window. Because AltiVec registers as so wide we've implemented a scrolling window to preserve screen real estate.

Dave: What's coming down the road?

Richard: Apple has revisited multi-processing with the introduction of Mac OS 8.6 using the MP hardware introduced a few years ago. For several releases we've had a version of MetroNub that was specifically designed for debugging MP tasks called "MetroNub for MP". Apple has dramatically changed their MP implementation with version 2.0 of the "Multiprocessing API Library" in Mac OS 8.6 and, as a result, the version of MetroNub for MP that shipped with Pro 5 is only compatible with MacOS 8.5.1 and earlier.

We're updating MetroNub for MP to support the new and improved MP library and the update will be available soon.

We're also planning to merge the two versions of MetroNub together. We originally split the extension into two separate versions because the old MP Library 1.4 had a huge memory overhead. Since the new library has a very low overheard of only 100K or so, we can merge the two versions together again. The merged extension will support MP debugging only on Mac OS 8.6 or later. If you want to debug MP Tasks on older versions of the OS, you can still use previous versions of CodeWarrior.

Another request that we've been listening to is to allow remote debugging of Mac applications from the IDE running on Win32 machines. After adding Win->Win and Mac->Mac debugging in Pro 5, we're now working on Win->Mac debugging for the next release. We hope this will encourage Windows developers to port their applications to Mac OS.

Dave: Any other changes on the CodeWarrior CDs?

Richard: We cleaned up the Mac OS Support folder by removing headers and libraries that belong to obsolete SDKs. We've also improved the layout by prominent placement of the OpenTransport and Universal folder that Apple provides. When new versions of these headers and libraries appear between CodeWarrior releases you'll easily be able to replace or add the new headers without having to walk the Mac OS Support folder hierarchy looking for the files that need to be removed.

We've also updated the MPW folder to the latest Tools CD from Apple and of course we've included versions of our MPW tools in that folder.