Actually, with our testing, this stepping bug happens immediately after the simulated 68K stops on a breakpoint. CW's debugger doesn't generally use the Palm OS debugging protocol's breakpoint support, instead setting actual TRAP #0 instructions in memory. When a breakpoint is hit under normal execution, switching the simulated CPU into trace mode causes the first instruction to be stepped over to actually step over two instructions.At the assembly level with PalmDebugger, there is a bizarre error such that the second instruction following a JSR or TRAP is skipped over by the debugger. The instruction is executed, but you can't single step into or breakpoint on it. So single stepping has these holes in the trace. What I've done for my own code is to add assembler NOP instructions in the skipped areas so I don't have to think about the invisible areas. For code you don't control, just be aware of what is happening and do lots of disassembly after skipping over a JSR/BSR/TRAP.
You see this with Palm Debugger since it generally sets a BP after the TRAP or JSR when you step over it. CW V9's debugger still has to deal with this bug, but its able to play around with breakpoints and "fake code" execution to bypass this bad skip behavior.
--
Ben Combee <[EMAIL PROTECTED]>
CodeWarrior for Palm OS technical lead
Palm OS programming help @ www.palmoswerks.com
--
For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
