Debugging Tips
Volume Number: | | 10
|
Issue Number: | | 5
|
Column Tag: | | PowerPC Series
|
Related Info: Memory Manager Dialog Manager
Debugging Tips for Mixed Mode
So thats what Im looking at when I crash!
By Dave Falkenburg, Apple Computer, Inc.
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
About the author
For having such short legs, Dave runs well - hes part of the team which just shipped Power Macintosh in record time. As keeper of the secrets of the Process Manager, hes something of a nexus for the myriad parts of the Macintosh which all seem to come together in that cauldron of code, a veritable witchs brew of bat wings and furless pets. Among other accomplishments, hes the guy who gave Ron Avitzur his first PowerPC 601 book.
When writing for Power Macs...
Youll need several tools. The obvious ones are a Power Macintosh and a development environment. Also handy, and not so obvious, are some bits and pieces. develop Issue #17 contains the dis dcmd. ETO #13 and recent developer CDs have MacsBug 6.5d6 (or later), and it has support for the new Power Macintosh Memory Manager.
When developing native applications for the Power Macintosh family, its pretty likely that you will stumble upon bugs which get introduced due to misuse of Mixed Mode Universal Procedure Pointers (UPPs).
Both the calling conventions and instruction set of any function are encoded within a data structure when that function has been wrapped by a UPP - two essential details which Mixed Mode needs in order to make your applications and plug-in modules work without knowing the sordid details of the emulator.
In the 68K Macintosh world, parameters to functions generally go on the stack or in registers, or sometimes both. PowerPC code generally puts all parameters in registers. On 68K, Pascal and C also have different calling conventions- each language passes parameters in the reverse order of its peer, and Pascal also insists on the callee cleaning up parameters. PowerPC has a single calling convention, which Mixed Mode will happily deal with.
Another important point is that PowerPC ProcPtrs arent pointers to code, but in fact, point at a data structure called a transition vector. This essentially makes them ProcHandles. We can take advantage of that when we diagnose crashes.
Another essential thing we rely on is the fact that the PowerPC and 680x0 instruction sets arent very similar - if you are looking at some sort of code in MacsBug, il <address> or dis <address> will probably tell you what kind of code you are looking at. For example, if we look at 680x0 code with dis, we will see something like the following.
dis 00142028
00142028
00142028 **undefined** | 4e754e56
0014202c **undefined** | fffc48e7
00142030 twi TO_LT|TO_GT,23622098,0x2a2e | 0f082a2e
00142034 **undefined** | 000c286e
00142038 **undefined** | 0010382e
0014203c **undefined** | 0014200d
00142040 subfic r16,r21,0x2a78 | 22152a78
00142044 **undefined** | 0b7c2a81
The same code as viewed with il looks more familiar:
il 0014202A
+15DA 0014202A LINKA6,#$FFFC| 4E56 FFFC
+15DE 0014202E MOVEM.L D4-D7/A4,-(A7) | 48E7 0F08
+15E2 00142032 MOVE.L $000C(A6),D5 | 2A2E 000C
+15E6 00142036 MOVEA.L $0010(A6),A4 | 286E 0010
+15EA 0014203A MOVE.W $0014(A6),D4 | 382E 0014
+15EE 0014203E MOVE.L A5,D0 | 200D
If you arent already familiar with the Mixed Mode Manager or the PowerPC Runtime Architecture, youll might want to read more about it in Inside Macintosh: RISC System Software before reading on.
UPP Basics
Emulated code can always call UPPs blindly, that is, without needing to use CallUniversalProc.
This was a necessary design principle for the emulator, because older applications, and large portions of the Macintosh Toolbox have no idea they are running on a PowerPC 601 microprocessor most of the time. JSR-ing through a UPP essentially executes a trap instruction which transfers control to Mixed Mode. Mixed Mode converts parameters, calls the PowerPC subroutine, and the returns to the emulated caller after translating the result code.
This may seem like magic, but is actually more mundane than mysterious. A UPP data structure starts with a trap (0xAAFE, a.k.a. _MixedModeMagic). When youre executing 68K code, and it JSRs through a UPP, the trap gets handled by Mixed Mode. Mixed Mode checks the rest of the data structure to figure out whether its 68K code, PowerPC code, or both. Mixed Mode then transfers control to the destination code, moving parameters from one mode to the other. So it might move 68K registers and/or stack arguments into PowerPC registers, or vice versa. What gets moved depends on the contents of the procInfo, a data structure which describes where parameters live, and where they should go.
PowerPC code must always use CallUniversalProc to call code which was passed as a ProcPtr of unknown type. All code which doesnt look like a UPP is assumed to be 68K code. This allows a PowerPC-based Dialog Manager to automatically call a ModalFilterProc regardless of whether or not the application is 68K code or PowerPC code.
Mixed Mode relies on the procInfo field in order to convert parameters and function result.
The biggest opportunity for making a mistake is in the creation of procInfo values. Much of the work has been done for you by Apple engineers in the Universal Headers. They defined constants and CallXXXProc macros for most of the Toolbox and OS routines which accept a ProcPtr, and its far more trouble-free to use them than to create your own.
UPP Symptoms
Well discuss the problems you can stumble across by breaking down the three major cases that Mixed Mode must deal with:
68K -> PowerPC, PowerPC -> 68K, and PowerPC -> PowerPC.
In almost all cases, a bad procInfo value is usually fatal, and very difficult to debug. Your programs stack can be completely munged beyond all repair. Its far easier to check your procInfos up front than to debug a bad one at run time! Always use the uppXXX, NewXXXProc, and CallXXXProc macros in the Universal Headers to keep you from screwing this up.
Bad procInfo values usually show up as either a crash with the PC pointing two bytes into the RoutineDescriptor data structure, or as mysterious crashes which have unexplained side effects. Remember those Macintosh 128K crashes when you accidentally slammed into the sound/disk pages? You wont have any easier of a time figuring out how you got there, and you dont even get to see the technicolor snowcrash or hear the machine-gun sounds.
Here are a variety of situations where something can go wrong. Ill treat each one separately.
Calling from 68K to PowerPC
Problem: Calling a PowerPC ProcPtr that hasnt been wrapped in a UPP.
You will see a 68K illegal instruction, and the PC will be somewhere in code where every third longword is a zero.
Whats happening is that Mixed Mode never got the chance to switch modes for you, so youre still trying to execute this code with the 68K emulator. Thats eventually going to generate an error, because the PowerPC instruction set is so different from the 68K instruction set. You can tell if this is what happened by doing a dis PC^ in MacsBug. Youll need the dis dcmd that came with develop Issue #17, or future developer CDs. If you see something like mflr r0 then this is probably what happened.
Problem: Calling a UPP with a bad procInfo
Check your procInfos, because bad ones will almost always get you. Ive told you this already, and Imay repeat it a time or two. Check out Inside Macintosh: RISC System Software, or <MixedMode.h> for information about creating procInfo values.
Calling from PowerPC to 68K
Problem: Calling 68K code as PowerPC code (i.e. you forgot to use CallUniversalProc)
This will manifest itself as a spurious interrupt or bus error in older versions of MacsBug. This usually turns up as a random jump into space. Remember that PowerPC ProcPtrs are really ProcHandles and the caller will actually dereference your LINK #-xx,A6 and try to use it as a pointer.
Take a look at your PC. Are you executing in the 0x4E560000 to 0x4E56FFFF range? If you are, odds are good that you did a jump into what turns out to have been a LINK instruction which was incorrectly treated as an address. LINKs opcode is 0x4E56.
Problem: Calling a UPP with a bad procInfo
Check your procInfos. An incorrectly-formed procInfo will get you. It is OK to call 68K code directly with CallUniversalProc. Thats because anything that doesnt begin with the MixedMode trap instruction is assumed to be 68K code, and that particular instruction was carefully chosen to not be a likely value to hit by accident.
Calling from PowerPC to PowerPC
I bet you didnt think of this case. It arises when a PowerPC-based manager must support both emulated callers, and PowerPC callers.
Problem: Calling a UPP without CallUniversalProc from PowerPC Code
All routine descriptors start with 0xAAFE, which is not only a trap, but also an illegal instruction for the PowerPC microprocessor.
This will manifest itself as either a PowerPC Illegal Instruction (a.k.a. spurious interrupt, for you MacsBug fans) or bus error depending on what is going on inside Mixed Mode at the time. This is similar to the Calling 68K code as PowerPC code above. If you get an illegal instruction, you can try doing a dm PC-2 and see if you find an 0xAAFE hanging around.
Problem: Calling a PowerPC procPtr as if it were a UPP
This case is pretty easy to spot - you will die in MacsBug with a 68K illegal instruction error. If you do a dis PC (using those wonderful PowerPC dcmds), you can see that the emulator is running, but for some reason the PC is pointing at mflr r0 and something like lwz r3,10(r1), two things a 680x0 emulator doesnt know how to do!
Problem: Calling a routine descriptor with a bad procInfo
Check your procInfos. Got the idea?
More tips and tricks
When developing native applications for Power Macintosh, try to do the following things to avoid getting into the trouble described above.
Source level debugging and single stepping are your friends - become familiar with one of the PowerPC-capable debuggers: CodeWarrior, Macintosh Debugger for PowerPC, or Jasiks Debugger. Keep your eyes open for others, as well.
Try to understand everywhere you use ProcPtrs in your code. This is where all those seemingly useless naming conventions we all use really pay off, like naming call function pointers XXXProcPtr, or all global variables gXXX.
Use the macros provided by in the Universal Headers to avoid botching procInfos. You can also make your code universal by using these macros. That means that you can compile for 68K or PowerPC without any further modification of your source code.
Remember, you dont need to use UPPs internally within your application if the code type is always known - UPPs are only needed when code can be called from either side of the mixed mode boundary. Supporting both emulated and PowerPC plug in modules is a good example of when to use a UPP.
Happy debugging!
For more information on items mentioned above:
CodeWarrior - a development environment from Metrowerks for both 68K and PowerPC, and it runs native on either platform. Available from the Mail Order Store. See page 89 for details, or call 310/575-4343.
Macintosh Debugger for PowerPC - a two-machine debugger from Apple. Requires one Power Macintosh (to debug) and any other Macintosh to do the driving.
Jasiks Debugger - a two-headed debugger from Steve Jasik, famous for his personal support. Available from the Mail Order Store. See page 89 for details, or call 310/575-4343. Jasik Designs may be reached at 415/322-1386.
dis dcmd - develop Issue #17, available from Apple.
Debugging On PowerPC, by Dave Falkenburg and Brian Topping - develop Issue #17, available from Apple.
MacsBug 6.5d6 - ETO #13 and recent developer CDs.