A breakpoint may be set anywhere in PM except for the following restrictions:
o Control must not be transferred to the second or third instruction of a breakpoint sequence. Thus a breakpoint must never span a label to which a branch instruction is expected to go.
o Breakpoints MUST be spaced apart by at least 3 PM instructions (since each breakpoint consists of 3 instructions) UNLESS they are entered in reverse order (i.e. break instructions BK96,BK95,BK93 will work, but BK93,BK95,BK96 will not).
This command will cancel a breakpoint that has previously been set using the "BK" command.
This will list the positions in PM of all breakpoints that have previously been set using the "BK" command.
It is ESSENTIAL to use "PR" to PROCEED from a breakpoint. "GO" would restart from the address given by bits 0-11 of DM0, skipping two instructions.
Similarly, "ST" (step) will only work from an existing breakpoint. NEVER step over a breakpoint that you have already put in. If you are approaching a breakpoint using "ST", either cancel it ("CB"), or proceed to it ("PR").
It is not possible to step from the starting address of the program (i.e. bits 0-11 of DM0). To achieve this effect, set a breakpoint at the beginning of the program (usually PM80), then "GO", then step, i.e.
*BK80 *GO *ST </per> If breakpoints or steps have been used, and it is desired to restart the program from the beginning, you must restart the processor with "GO80" not "GO", since using breakpoints or steps overwrites the initial contents of DM0.
Either stepping or proceeding (from a breakpoint) deletes the initial breakpoint; thus a breakpoint can only be used once. For example, when stepping around a loop, the breakpoint disappears after you have reached it. So it must be replaced each time (when you have stepped more than 3 instructions away).
The "ST" command will step through a BC (branch on condition) instruction, decoding the condition codes in order to decide which branch to take.
"ST" will step over BAL and BALR (branch and link) instructions, which are used for subroutine calls. It will therefore have the effect of a " STEP " rather than " STEP/INTO " in VAX debugger terminology - the subroutine will be called and executed; stepping will be resumed after the return.
"ST" does not decode BCR, BCT, BCTR, BXH or BXLE (in fact any of the branch instructions except BC). So stepping
through these is to be avoided.
when attempting to step or proceed usually indicates a problem caused by
- Placing a breakpoint over a label to which control has branched.
- Stepping over a breakpoint
- Stepping over a branch instruction (except BC)
- Illegally overlapping breakpoints
These problems are discussed above. Recovery from this usually means reloading the program and starting again.
The following example of an editing session using SNOOPY demonstrates setting and cancelling breakpoints, and the use of the Step, Proceed and Go (ST,PR and GO) commands. The carriage returns following each command are omitted for clarity.
1. Show the original contents of PM90-PM92 using the "PM" command
*pm90 PM00000090= 58A0D090 L 10,144(0,13) PM00000091= 50A004EC ST 10,1260 PM00000092= 41A00000 LA 10,02. Set a break point at PM90, dump the contents of PM90-PM92 to show that the original instructions have been replaced by the 3-instruction breakpoint code.
bk90 ( set a breakpoint at PM90 ) *pm90 PM00000090= 50E000E0 ST 14,224 PM00000091= 09E00000 BALR0 14,0 PM00000092= 47F00064 BC 15,1003. Set a break point at PM97 in the same wayPM00000097= 50D00030 ST 13,48 PM00000098= 58300200 L 3,512 PM00000099= 5930D04C C 3,76(0,13) bk97 ( set a breakpoint at PM97) *pm97 PM00000097= 50E000E0 ST 14,224 PM00000098= 09E00000 BALR0 14,0 PM00000099= 47F00064 BC 15,1004. Set a break point at PM9C - show breakpoints - cancel a breakpointbk9C ( set a breakpoint at PM9C) *sb ( show breakpoints) Break # 1 at 00000090 Break # 2 at 00000097 Break # 3 at 0000009C *cb9F ( cancel a breakpoint at 9F) Break not found ( no such breakpoint ) *cb9c ( cancel a breakpoint at 9C) *sb ( show breakpoints ) Break # 1 at 00000090 ( breakpoint at 9C has gone) Break # 2 at 000000975. Start the SSP - and stop at first breakpoint*dm0 ( display contents of DM0 ) $PSW0 DM00000000= 00008080 32896 "...."
go ( start the SSP at contents of DM0 ) *sh ( Display Break and PSW and CSR0 ) ( -have stopped on break point at PM90)
break at 90 58A0D090 L 10,144(0,13) Show: Retcod=00000000 - PSW=00008093 - CSR0=0106F110 </pre?
6. Step then proceed to next break point*st ( step from breakpoint) break at 91 50A004EC ST 10,1260 ( stops at PM91) *st ( step from breakpoint) break at 92 41A00000 LA 10,0 (- stops at PM92) *sb ( show breakpoints ) Break # 1 at 00000092 Break # 2 at 00000097 *pr ( proceed from a breakpoint to next breakpoint ) *sh ( Display Break and PSW and CSR0 ) break at 97 50D00030 ST 13,48 Show: Retcod=00000000 - PSW=0000809A - CSR0=0106F1107. Step, then proceed to end of program*sb ( show breakpoints ) Break # 1 at 00000097 *st ( step to PM98 ) break at 98 58300200 L 3,512 *st ( step PM99 ) break at 99 5930D04C C 3,76(0,13)8. Restart processor, and run program wihout breakpoints
*pr (proceed to next breakpoint or end of program if no more breakpoints) *dm0 ( display contents of DM0 ) $PSW0 DM00000000= 00008099 32921 "...."go80 ( use GO80 command as DM0 does not contain 8080 hex ) *sh Show: Retcod=00000000 - PSW=00008080 - CSR0=0106F132
Five lines of special code are also downloaded into the SSP starting at the PM address 64 (given by PM_P_BRKADD_1 in BNLSYS). Two locations in DM starting at E0 (given by DM_P_BRKPT in BNLSYS) are also used to store R14. The register dump area is at DM40 (given by DM_P_RDUMP in BNLSYS).
These particular locations are acceptable for both the SLAC and BNL SSP "operating systems", so that the SNOOPY breakpoint handler will work with both SLAC and BNL SSP files.