Balance of Power: MacsBug for PowerPC
By Dave Evans and Jim Murphy
Where would we be without our venerable friend MacsBug? Those long debugging sessions, with soda cans piling up, would be so lonely. Like a trusted buddy, only a key press away, MacsBug has helped us solve the toughest problems and has taken us into the very core of the Macintosh.
Yet now the core has changed. The Macintosh has transmuted into a RISC powerhouse, and its new runtime environment is a foreign place to the old MacsBug. But instead of leaving our friend in the past, Apple is developing a next-generation MacsBug. The next MacsBug, version 6.5, supports PowerPC debugging with the same commands that you already know. An early release of the new MacsBug is provided on this issue's CD.
A QUICK LOOK
When we're confronted with a MacsBug display that heralds the beginning of a new debugging challenge, our first questions are "Where are we?" and "How did we get here?" MacsBug has always provided tools and information to help us quickly answer these questions. The stack crawl commands, for example, show not only what code you're executing but also how you got there. On a Power Macintosh, however, the old MacsBug often failed at tasks like the stack crawl. The PowerPC architecture changes fundamental structures -- such as stack frame formats -- and introduces new hurdles like mixed-mode switches and native code. The key goal of the new MacsBug is to restore the functionality you need in
order to debug on a Power Macintosh.
The new MacsBug adds many features to satisfy this goal. It lets you disassemble, trace, and step through PowerPC code. You can set breakpoints in PowerPC code, and easily find out what code fragment you've interrupted and what native symbol is closest. And you can display a stack crawl that includes both PowerPC and 680x0 stack frames. Let's take a closer look at these and other new features.
DISASSEMBLING POWERPC CODE
The new MacsBug will disassemble both PowerPC and 680x0 code. Some commands are now sensitive to which type of code is executing. The td (total display) command will show the PowerPC register set during execution of native code, and the 680x0 emulated registers during execution of 680x0 code. When used without an address, the il and ip commands will disassemble the code currently being executed, whether PowerPC or 680x0; however, when an address is specified with
il and ip, MacsBug will disassemble 680x0 code at the specified address.
We've introduced a few new commands to force disassembly of PowerPC native code. They include the following:
- ilp: Instruction list of PowerPC code
- ipp: Instruction half-page list of PowerPC code
- idp: Instruction display one word as PowerPC code
- dhp: Disassemble hex as PowerPC code
- brp: Set breakpoint in PowerPC code
To demonstrate, we'll set a native
breakpoint in the Memory Manager with brp __SetHandleSize. After we type g and wait for a second, MacsBug interrupts with this display:
PowerPC breakpoint at 000A06C4 __SetHandleSize
We type the il command and see the following (notice the familiar breakpoint bullet and the asterisk showing the current program counter location):
Disassembling PowerPC code from 000A06C4 __SetHandleSize +00000 000A06C4 **mflr r0 +00004 000A06C8 stmw r26,-0x0018(SP) +00008 000A06CC stw r0,0x0008(SP) +0000C 000A06D0 stwu SP,-0x0170(SP) +00010 000A06D4 lwz r30,0x0000(RTOC) +00014 000A06D8 addic r7,SP,72 +00018 000A06DC lwz r26,0x0000(r30) +0001C 000A06E0 ori r31,r4,0x0000 +00020 000A06E4 stw r7,0x0000(r30) +00024 000A06E8 ori r29,r5,0x0000 +00028 000A06EC lwz r3,0x0004(RTOC) +0002C 000A06F0 bl __HSetStateQ+013C +00030 000A06F4 lwz RTOC,0x0014(SP) +00034 000A06F8 ori r28,r3,0x0000 +00038 000A06FC addic r3,SP,72
From here we can display any PowerPC register, step or trace through the code, or ask for our location using the improved wh command. The wh command now lists which code fragment contains the address, using the code fragment export symbols to display the nearest earlier symbol. In this example, we interrupted at __SetHandleSize in the MemoryMgr code fragment, so wwh produces this:
Address 000A06C4 is in the System heap at 00002800 at __SetHandleSize This address is within the code fragment named "MemoryMgr". It is 000021D4 bytes into this heap block: Start Length Tag Mstr Ptr Lock * 0009E4F0 00009050+04 R 00002BF0 L
CRAWLING AROUND TOGETHER
MacsBug version 6.5 distinguishes between PowerPC and 680x0 stack frames but will display them as a unified stack crawl. This makes it very easy to determine where you are and where you've been. Since the PowerPC version of the Mac OS still contains a substantial amount of 680x0 code, you'll often see references to 680x0 callers in the stack crawl. Otherwise, expect to see the nearest earlier code fragment symbol to each caller. A sample stack crawl, displayed with the sc command, would look like this:
Frame Caller ISA 01D87FB2 00013CA0 PPC 'MyApp'+1A0 01D87F4A 00043050 PPC 'MyApp'+2F450 01D87EF0 4085FF06 68K ComponentDispatch+26 01D87EC8 4085FFE6 68K ComponentDispatch+106 01D87E50 00063144 PPC 'NativeComponent'+40
Here you can see that we're executing a native application with the exported main symbol MyApp. The application calls a subroutine at MyApp+1A0, leaving the first stack frame that we see here. Then at MyApp+2F450 the subroutine appears to call the 680x0-based Component Manager. We assume this because the next two stack frames are marked "68K" and appear within the ComponentDispatch code. The Component Manager then calls native code with the symbol NativeComponent. The last frame is generated when NativeComponent calls a subroutine.
EVEN MORE NEW FEATURES
Besides support for native Power Macintosh debugging, the new MacsBug adds other exciting new features, including:
- multiple debugger preferences files
- better ROM symbols using ROM map files
- an improved dcmd format
- significant performance improvements on 68040-based Macintosh computers
We once used ResEdit to construct a single MacsBug preferences
file with all our favorite dcmds and templates. Those days are over: the new MacsBug version will load up to 32 preferences files that you provide. And if you haven't discarded the ROM list files provided with MPW, you can build them and use the resulting ROM map files with the new MacsBug. Put the map files in the new MacsBug preferences folder to use the map's symbol information. When disassembling or displaying addresses in the ROM, MacsBug will then display
The improved dcmd format adds new action calls and an expanded parameter block structure, which provides full access to the PowerPC register set and machine state. Although this doesn't give you special support for developing PowerPC-native dcmds, you now have access to valuable internal state information. With this new information, your dcmds can do things that were previously reserved for Apple dcmds, such as tdp (total dump PowerPC), which was introduced in the article "Debugging on PowerPC" in develop Issue 17. This dcmd, among others from Apple, has intimate knowledge of how the PowerPC system software works. With the new dcmd format, this intimate knowledge is no longer necessary since MacsBug provides access to everything you'll need.
The new dcmd format has been designed with maximum flexibility in mind. Your dcmds can check at run time for the availability of MacsBug features. When new callbacks are defined, you can check whether MacsBug supports the calls, rather than being tied to a specific MacsBug version.
On 68040-based Macintosh computers, MacsBug will perform most tasks much faster, and with an important side effect. The new MacsBug doesn't flush the 68040 processor cache nearly as often, greatly improving performance for most commands. The key side effect is for bugs related to cache flushing: in the past, MacsBug would flush the cache frequently enough to make these bugs hard to reproduce when you're stepping or using breakpoints; the new MacsBug, with its selective flushing, should allow you to more readily reproduce this type of problem.
IT'S LOG, LOG, LOG!
Here at Apple, bugs are usually found by test engineers using automated scripts and manual testing. When they find a bug in our code, we're rarely nearby to analyze it immediately. Therefore, they collect key information so that we can later reproduce the problem. One useful piece of information they collect is
called a standard log.
The standard log is a sequence of MacsBug commands that are run after a crash or interrupt -- for example, a register display and stack crawl. These commands are logged in a text file, and the result is copied into a report that describes the problem. Having this information in the problem report saves significant time and sometimes provides enough detail to resolve the problem immediately. MacsBug version 6.5 makes this log useful on the Power Macintosh. Its improved stack crawl, native disassembly, and PowerPC register display provide key information for later analysis. We recommend that you incorporate a standard log into your testing process; you'll find ours included as the StdLog macro.
You can read the release notes provided on the CD for detailed descriptions of these and other improvements. We hope you'll install the new version of MacsBug