John Wittkoski (jpw@insoft.com) wrote something like this:
>I'm trying to learn more about the ADB problem on the IIsi. The specifics
>aren't important right now, but the thing hangs in one of the ROM routines.
>I wanted to step through some of the code to see where it is hanging,
>but once I get into the debugger, the 'step' command acts like the 'continue'
>command, so I can't follow what happens - it just hangs again.

I'm no authority on this, but it seems to me that it is impossible to 
'step' through ROM. The way I understand it, the debugger tries to use this 
algorithm to 'step':
1) save the instruction after the current instruction
2) insert a trap after the current instruction
3) execute the current instruction
4) (control returns to the debugger via the inserted trap)
5) replace the saved instruction (which is now current)
In ROM (Read Only Memory), this algorithm fails, since you cannot write the 
necessary trap instruction to ROM. This results in the 'step' command 
acting like a 'continue' command (without the trap, control never returns 
to the debugger; the processor simply continues to execute instructions in 
ROM).

If you still want to follow what happens, you will have to (a) copy the ROM 
routine(s) to RAM so that 'step' will function properly, or (b) manually 
follow the ROM listing (read it, not execute it), and try to decipher where 
the problem lies (I would guess a Mac ROM trap has been redefined by 
NetBSD/Mac, or the ROM is trying to use a global variable in RAM that is 
occupied by something like the NetBSD/Mac kernel, or the ROM routine was 
called improperly [wrong number of arguments on the stack, for instance]).
The second approach is more laborious and time consuming, but it is do-able,
with a decent disassembler.

/\/\/\_ Eric Van Buren, vanburen%flovax.dnet@rocdec.roc.wayne.edu
\ \ \   Immunology & Microbiology
 \_^_/  Wayne State University, Detroit, Michigan, USA