🚀 go-pugleaf

In article <10442.740.forumexp@mts.rpi.edu>, Greg_d._Moore@mts.rpi.edu
(Commander Krugannal) says:
>
>     Looking over some old code fragments today, I cam across a call
>   to int 3. Neither I nor any of the other programmers in the office
>   could recall what it did. Does anyone know?

Ah, how I long for easy questions like this!

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.

Of course, I haven't mentioned anything so far that couldn't be done with, say,
Int 0xFF (Yeah, I like C.).  What makes Int 3 special is that it can be coded
in only ONE BYTE, whereas all other interrupts take two bytes.


Personally, I find the NMI interrupt (Int 2) much more interesting ...


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 ..."

Int 3 is the breakpoint interrupt.

Tor Brekke
Email: torb@idt.unit.no

  Int 3 sets a breakpoint for program execution, useful for debugging, but
 not much else (I can't think of anything at least). When your program
 calls it, it stops to let you inspect variables and whatever else you want
 to play with.
  
                                      -Sean Cox
                                       Skeeve@mts.rpi.edu
                                       skeeve@pawl.rpi.edu

Int 03h (along with 01h) is used for debugging programs.
Debuggers load an interrupt 03h instruction at breakpoints and
then let the program to run. Int 01h is used for traps.



ramin firoozye
rp&A Inc. SF.

In article <10442.740.forumexp@mts.rpi.edu> Greg_d._Moore@mts.rpi.edu (Commander Krugannal) writes:
$     Looking over some old code fragments today, I cam across a call
$   to int 3. Neither I nor any of the other programmers in the office
$   could recall what it did. Does anyone know?

   int 3 is the breakpoint interrupt.  It's a one-byte instruction so
that it's easier for a debugger to put it there in place of whatever
other instruction was there.  Of course, you _can_ use it for anything
you like - you could write a little routine to play "Yankee Doodle
Dandy" whenever int 3 was executed if you wanted.  But it was designed
for use as a breakpoint.
-- 
Stephen M. Dunn                               cs4g6ag@maccs.dcss.mcmaster.ca
          <std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
       "I want to look at life - In the available light" - Neil Peart

In article <90017.100521CMH117@PSUVM.BITNET> CMH117@PSUVM.BITNET (Charles Hannum) writes:
>
>Ah, how I long for easy questions like this!
>
>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.  Single stepping is accomplished
by setting the TF (trap flag) bit in the flags register.  When the CPU
executes an instruction when this bit is set, it takes Int 1, not Int 3. The
CPU handles the exception by pushing cs:ip and the flags on the stack and
turning off the trap flag bit in the current flags (so the single step 
exception handler doesn't generate single step exceptions).

Int 3 is the break point exception, a single-byte opcode that vectors the
CPU though int 3 when it executes it.


-- 
Jerry Gardner, NJ6A					Altos Computer Systems
UUCP: {sun|pyramid|sco|amdahl|uunet}!altos86!jerry	2641 Orchard Parkway
Internet: jerry@altos.com				San Jose, CA  95134
I don't speak for Altos, they don't speak for me.       946-6700

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 ..."