OFFICIAL ADVICE ON DEBUGGING PART #2

The problem some of you have had with Part #2 is because you want to debug
your exception handler by using the debugger.  Unfortunately, since the
debugger is an exception itself (break 1), sometimes the debugger is 
interfering with your debugging.

I have the following suggestions, having developed them by writing parts 1,2,3
myself and in helping students:

1) Set a breakpoint at the instruction AFTER your "break n" instruction.
   Then examine the results of the break, paying special attention to the 
   registers and any memory locations modified.

   For example, in readY2Kstring, the first "break n" is immediately followed
   by:     bnez    $a3, new_return 
   Set a breakpoint at the bnez.  

2) Here is the only way that I know of to step through YOUR exception
   handler.   I have succeeded in performing this with both my program and 
   other students.  This worked wonderfully for me! 

   STEPS:
   a) At the very beginning of main,  before you ever execute a syscall
   instruction in your application,  modify your source file to "call one 
   of your Y2K user trap routines" by initializing $a3 to ......, etc.  
   	For example:
		main:   jal  init     #initializes whatever needs to be done
			li   $a3, 0
			la   $a2, dummydate
			break <n>
			...
   b) Make sure that "init" does NOT contain a syscall instruction.
   c) Set a breakpoint at an instruction before break.  e.g.:  li $a3, 0
   d) Select "Go" which will "go" until the breakpoint is detected.
   e) Then start stepping through your program.  After stepping through the
	instructions: li, la, and  break, control will transfer to the 
        P5excphandler.  
   f) Write down the value of the EPC register and the Cause Register.
      Watch them as you continue stepping.  (If they change, then this won't
      work.)
   g) Continue stepping and then eventually you'll step into your exception
      handler and be able to fine tune your error analysis.

3) BEWARE the following attempts at debugging an exception handler.

   a) Once you have made a syscall in YOUR application, you will probably not 
      be able to "step" through the exception handler again.   This combination
      of events is the source of complaints that the cause register = 0x1c

      Remember, syscall is a X_ _ _ to O_ _ _ _ _ _ _ _   _ _ _ _ _ _  Process.
			      f e r     p e r a t i n g   S y s t e m

   b) Do not set a breakpoint inside the p5excp.handler

   c) Do not set a breakpoint at the instruction:  break n

   d) Do not set a breakpoint inside your user-defined handlers