[ros-kernel] Kernel Debugger doesn't correctly identify all types
of calls
Gregor Anich
blight at blight.eu.org
Sat May 1 21:43:11 CEST 2004
Hi!
Today I have tested KDB a bit and it works well but I have seen it
stepping over indirect calls like the following code:
FF 15 F4 68 87 69
This is the code which is checking wether the current instruction is a
call to decide wether to step over it (break after the instruction and
continue) or single-step:
/* Check if the current instruction is a call. */
while (Eip[0] == 0x66 || Eip[0] == 0x67)
{
Eip++;
}
if (Eip[0] == 0xE8 || Eip[0] == 0x9A || Eip[0] == 0xF2 || Eip[0] ==
0xF3 ||
(Eip[0] == 0xFF && (Eip[1] & 0x3C) == 0x10))
...
Reading the Intel instruction reference I found out that 0xFF is the
primary opcode,
0x15 is the ModR/M byte and F4 68 87 69 is the address (0x698768F4)
The ModR/M byte consists of the following parts:
bits 0..2 R/M
bits 3..5 Opcode/Reg
bits 6..7 Mod
From the Intel Manual: "The mod field combines with the r/m field to
form 32 possible values: eight registers and
24 addressing modes."
So for the previously mentioned instruction the ModR/M byte is
0b00010101/0x15 (Mod = 0, Opcode = 2, R/M = 5)
I think the only thing relevant for the debugger to identify wether this
is a call or not is the Opcode part of the ModR/M byte but the check
(Eip[1] & 0x3C) == 0x10 masks bits 2..5 (0x3C = 0b00111100) which
includes the Opcode and the highest bit of R/M - I think it should be
0x38/0b00111000
The code is in ntoskrnl/dbg/kdb.c, line 677
If anybody who knows x86 machine code can confirm this it would be nice
if someone changes the code.
--blight
More information about the Ros-kernel
mailing list