65 lines
4 KiB
Markdown
65 lines
4 KiB
Markdown
---
|
|
layout: page
|
|
title: "x86 Instructions: ICEBP"
|
|
permalink: /docs/x86/ops/ICEBP/
|
|
---
|
|
|
|
ICEBP (0xF1)
|
|
---
|
|
|
|
### Description
|
|
|
|
From [http://www.rcollins.org/secrets/opcodes/UMOV.html](http://www.rcollins.org/secrets/opcodes/UMOV.html):
|
|
|
|
An undocumented op code that will make debugging run-time code on an ICE easier. Normally, to set an arbitrary
|
|
breakpoint in a program which was loaded by an operating system, you must perform a laborious task of figuring out
|
|
where your program was loaded in memory. Follow that process with an equally laborious task of calculating the
|
|
offset in memory which corresponds to the desired breakpoint. This process is exacerbated by programs which use
|
|
many segments, especially many code segments. Now for one final complication, consider that your program switches
|
|
from real mode, to protected mode, with paging enabled, and you are not using a 1-to-1 mapping of physical to
|
|
virtual memory. You want to talk about a nightmare just to figure out where to set a breakpoint?
|
|
|
|
All of these problems are eliminated, simply by using this instruction -- provided you know its caveats.
|
|
|
|
Undocumented: Available to all 80386-class (and above)
|
|
processors as described herein.
|
|
May be available to 80286 processors, but
|
|
implemented in a different manner.
|
|
Useful to BONDOUT (ICE) processors.
|
|
Especially useful during ICE debugging.
|
|
Useful in production source code.
|
|
ICEBP
|
|
Flags: ICE Break Point
|
|
+-+-+-+-+-+-+-+-+-+ +----------+
|
|
|O|D|I|T|S|Z|A|P|C| | 11110001 |
|
|
+-+-+-+-+-+-+-+-+-+ +----------+
|
|
| | | | | | | | | | | F1 |
|
|
+-+-+-+-+-+-+-+-+-+ +----------+
|
|
|
|
The name ICEBP was given by a pre-production Intel ICE that had the ability to disassemble undocumented op codes.
|
|
The name ICEBP is a misnomer because the instruction is actually a single byte single-step exception (INT-01).
|
|
|
|
How you use ICEBP depends upon whether or not you are using an 80386 ICE, Intel486 ICE, or Pentium ICE. For the
|
|
purposes of this article, usage of ICEBP on 80386 and Intel486 are identical. Pentium enables ICEBP a little
|
|
differently than its predecessors.
|
|
|
|
Two effects of ICEBP -- 80386 and Intel486
|
|
|
|
ICEBP has two operational effects: When Interrupt Redirection (IR) is disabled, ICEBP acts as a single byte INT 01.
|
|
When this instruction occurs, it invokes the standard INT 01 handler. Unlike the single step exception (Trap Flag=1),
|
|
this instruction does not set the trap flag on the stack image, nor modifies the trap flag on the stack image.
|
|
Therefore, upon termination of the INT 01 handler, execution continues without further occurrences of the single
|
|
step breakpoints.
|
|
|
|
When Interrupt Redirection is enabled, ICEBP will attempt to invoke the hardware breakpoint handler associated with
|
|
an In Circuit Emulator (ICE). If the processor is a production CPU, the processor will hang. If the processor is a
|
|
BONDOUT CPU attached to an ICE, ICEBP will cause the ICE to break from emulation. On an Intel ICE, the message
|
|
"Unknown Breakpoint at address xxxx:xxxx:xxxxxxxx" appears on the screen.
|
|
|
|
There are two ways to enable Interrupt Redirection. It can be done by directly programming DR7 (see "Undocumented
|
|
Bits in DR7"), or this bit can be set (indirectly) using an ICE. To set this bit using an ICE, you must first be in
|
|
HALT mode. Any "go til" command that uses the debug registers will enable Interrupt Redirection. For example,
|
|
"go til 1234:5678 execute," "go til 1025:3245 write," or simply "go til 0 p" will enable Interrupt Redirection.
|
|
This work because the ICE actually uses the debug registers to trap debug exceptions. Of course, this directly
|
|
implies that any time the ICE uses the debug registers to signify break points, and emulation halts, it does so
|
|
following an INT 01 to the ICE break point handler (since interrupt redirection is enabled).
|