Cause execution to continue from a given point and optionally set 1 or more 'go' breakpoints.

Syntax:

ÄÄÄÂÄ  G   ÄÄÂÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄ
     ÃÄ  GS  ÄÄ´  ÀÄ = ÄÄÄ start-addr ÄÄÙ  ÀÄÄÄ break-addr ÄÂÙ
     ÀÄ  GT  ÄÄÙ                                           ³
                                             ÀÄÄÄÄÄ , ÄÄÄÄÄÄÙ

Parameters:

• Default)
  Continue execution from the current CS:EIP.
  S
  The go-special command causes the high-resolution time interval to be recorded from the point GS command is issued to the point that the Kernel Debugger is re-entered as the result of a break-point firing.

  Notes

  No account is taken of the Kernel Debugger overhead when calculating the time interval.

  When the Kernel Debugger re-enters, for whatever reason, the interval timer is cancelled until another GS command is executed.

  If the reason for entry is for reasons other than the firing of a sticky or go breakpoint then in addition to cancelling the interval timer no time message displayed.

  T
  This option causes the Kernel Debugger's trap vector handlers to be removed temporarily from the IDT and the system's re-instated until after then next instruction has executed. After execution of the next instruction the the Kernel Debugger's V commands are re-instated.

  This is a convenience option that saves manually unhooking a Kernel Debugger trap vector handlers from the IDT. using a command sequence similar to:

  VC n
  T
  VS n
  G
  

  start-addr
  The address from which execution is to continue. This must be a valid address for the current context. If start-addr is omitted then execution continues from the current CS:EIP, as shown by the R command.

  Warning: Be very careful to ensure that the start address is valid for the privileged level and addressability of the code and data selectors in use. If the Kernel Debugger attempts to load a segment register that is invalid the system may trap in the debugger code.
  

  break-addr
  Up to ten go breakpoints may be specified. These are temporary breakpoints set in addition to any sticky breakpoints set by the B commands. When the Kernel Debugger is next entered, for whatever reason, all go breakpoints are cleared.

  If break-addr is omitted then the system continues execution until:

  A fatal exception occurs
  An Internal Processing Error (IPE) occurs.
  A sticky breakpoint fires
  A non-maskable interrupt occurs
  An INT 3 instruction is executed
  The user enters Ctrl-C from the debugging console.

  Results & Notes:

  The system continues execution until the Kernel Debugger is re-entered. If the reason for entry is other than a breakpoint firing then the R command is automatically executed followed by one of the following command prompts:

  >

  (signifies a command prompt in real mode)
  #
  (signifies a command prompt in protect mode with paging disabled)
  -
  (signifies a command prompt in V86 mode with paging disabled)
  ##
  (signifies a command prompt in protect mode with paging enabled)
  --
  (signifies a command prompt in V86 mode with paging enabled)

  If an error situation caused entry to the Kernel Debugger then a diagnostic message may be generated by the failing code writing directly to the Kernel Debugger's communications port.

  If entry was caused by a Kernel Debugger trap handler receiving control then a message from the trap handler will be displayed. See the V command for details.

  If a breakpoint caused the Kernel Debugger to receive control then commands associated with the breakpoint that fired will execute. See the B commands for details.

  If a go-special was interrupted by a breakpoint firing then the following message appears before any output associated with the breakpoint:

  Go Time (tics) = 017fb (hex) = 5145 (uSec)
  
  

  This shows the time interval in both timer-ticks and equivalent number of micro-seconds.

  ---

  [Back] [Next]