In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
  
Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel

RTP Series - RTP25

The main debugger controller program. The debugger itself is actually two programs, RTP25 (which handles the basic debugging functions and takes little memory space on the stack), and DEBUGGER which is a much larger program which handles all of the complicated debugging logic. (Because of this it is only paged onto the stack when required). The following documentation does not differentiate between RTP25 and DEBUGGER.

RTP25 is invoked at the first linemark opcode in a compiled program when break key status is on. As linemarks are generated by the compiler when it comes to an @FM or a LINEMARK statement, the debugger cannot be used on symbolics (No @FMs!).

Due to the new "Windowing" functionality of AREV it can sometimes be difficult to see what the program was doing before it entered the debugger. To review the state of the screen just before the debugger was invoked, enter S at the ! prompt. This will display the screen image as it was and then wait for a key to be pressed to return to the debugger.

When a program breaks in a system subroutine, the break message does not indicate what subroutine was calling the system subroutine. This is fine when you are test running a single program and know what the problem is, but when you are testing a suite of programs and the problem could be in any one of a number of subroutines it can be very inconvenient. For example, in one of your programs you may make the following call to MSG without assigning ANS first


0001           CALL MSG("Yes","RC",ANS,"")

This would crash with a "SCRIBE line 1 broke because..." message.

To find out what programs have been called to reach the breakpoint, enter R at the ! prompt, and the subroutine return stack will be displayed. In the above example

         RTP25
         SCRIBE        (prompt for input)
         MSG           (message processor)
         TEST          (our program)
         RTP18         (RTPSeries Passim)
         TCL
         CATALYST
         WINDOW
         RTP18
         RTP2

If string space availability is a contentious issue with you when developing programs, the ability to stop a program and see how much memory is currently in use is a must. This is achieved using the # command. Typing # at the ! prompt returns a message similar to the following

    !#   Statistics after Garbage Collect
         There are 1399 descriptors used
         There are 199548 bytes of string space free
         The PROGRAMS array consumes 104123 bytes of memory

If you routinely separate your object code from your source code and symbol table then you will realise that when debugging you cannot access your variables by name. To get around this problem use the undocumented SY command. Enter SY filename, recordname and the debugger will load the Symbol table from the file recordname combination given.

Whilst working on a program in a networked environment you may wish to lock it so as to prevent others from making amendments. To do this enter LOCK filename,recordname or to lock the entire file enter L O C K filename. To unlock these locks enter the documented UNLOCK filename, recordname or UNLOCK ALL.

Be aware that in the basic RTP25 debugger, entering O is synonymous with entering O F F so be careful not to slip until DEBUGGER is invoked!

If you have not already done so, it is worth becoming familiar with the SO and S T commands documented in the "Advanced Revelation Technical Reference Manual".

(Volume 1, Issue 3, Pages 6,7)
Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel