Greg_d._Moore@mts.rpi.edu (Commander Krugannal) (01/17/90)
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?
Greg_d._Moore@mts.rpi.edu
Disclaimer: Why do I need one? everyone else has one!CMH117@PSUVM.BITNET (Charles Hannum) (01/17/90)
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 ..."
torb@idt.unit.no (Tor Brekke) (01/18/90)
Int 3 is the breakpoint interrupt. Tor Brekke Email: torb@idt.unit.no
skeeve@pawl.rpi.edu (Sean C. Cox) (01/18/90)
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.edurpA-Inc@cup.portal.com (RP and Ainc) (01/18/90)
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.
Ralf.Brown@B.GP.CS.CMU.EDU (01/18/90)
In article <D1R7N=@rpi.edu>, skeeve@pawl.rpi.edu (Sean C. Cox) wrote: } } 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 Turbo Pascal versions 1 through 3 used INT 3 to implement Control-Break checking when enabled by the {$U+} compiler directive. An INT 3 would be inserted after the code for each statement, and the interrupt handler would check the keyboard, aborting or returning as appropriate. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 "How to Prove It" by Dana Angluin Disclaimer? I claimed something? 14. proof by importance: A large body of useful consequences all follow from the proposition in question.
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (01/19/90)
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 Peartjerry@altos86.Altos.COM (Jerry Gardner) (01/19/90)
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
CMH117@PSUVM.BITNET (Charles Hannum) (01/19/90)
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 ..."