Aug 99 Factory Floor
Volume Number: 15
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
.
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.
Finally, we've added a Sherlock index to the reference CD so all HTML and text
documents have been searched along with the example code.