🚀 go-pugleaf

In article <177@altos86.Altos.COM>, jerry@altos86.Altos.COM (Jerry Gardner)
says:
>
>In article <90017.100521CMH117@PSUVM.BITNET> CMH117@PSUVM.BITNET (Charles
>Hannum) writes:
>>
>>Int 3 is the "debugging" or "single step" interrupt.  Debuggers (including
>the
>>infamous DOS DEBUG program) insert Int 3's at "breakpoints".  A breakpoint
>>refers to either the end of the next instruction (as with single-stepping) or
>>a user-defined breakpoint, as with the G(oto) command in DEBUG.  When the CPU
>>executes the Int 3, the debugger regains control.
>
>
>Unfortunately, it looks like easy questions like this one trip you up :-)
>
>Int 3 is not the "single step" interrupt.

I refer to it as the "single step" interrupt mainly because that is what DEBUG
uses.  Also, Int 1 is brain-damaged and unsafe.  If, for example, an asyncron-
ous interrupt occurs just as the single step interrupt is activated (which
seems at first an unlikely occurence, but has happened to me many times) Int 1
will still be activated, but the interrupt controller will not be reset, so
nice things like the KEYBOARD INTERRUPT will not work properly.  To fix this,
most Int 1 handlers *attempt* to recognize asynchronous interrupts and allow
them to continue if necessary, patching themselves into the stack so that the
debugger will regain control upon return from the interrupt.  But this is still
unsafe.  You are best advised not to use it.

Besides, single-stepping is itself a brain-damaged way to debug programs.  For
example, you can't skip over procedure calls or pieces of code that you *know*
work.  Single stepping should only be used in critical pieces of code where it
is ABSOLUTELY ESSENTIAL to trace every instruction.  In general, it is a waste
of time.


Virtually,
- Charles Martin Hannum II       "Klein bottle for sale ... inquire within."
    (That's Charles to you!)     "To life immortal!"
  cmh117@psuvm.{bitnet,psu.edu}  "No noozzzz izzz netzzzsnoozzzzz..."
  c9h@psuecl.{bitnet,psu.edu}    "Mem'ry, all alone in the moonlight ..."