Mail Archives: opendos/2001/09/04/08:29:47
Hi all,
some time ago I learned here about a few problems with DR-DOS DEBUG.
I have also noticed some.
When tracing a program, and CS:IP points to instruction that references
memory, the contents of the memory cell to be accessed is displayed
to the right of the disassembled instruction (or in the next line,
if the instuction is particularly long), e.g.,
AX=0000 BX=0000 CX=0000 DX=0000 SP=FFFC BP=0000 SI=0000 DI=0000
DS=19E8 ES=19E8 SS=19E8 CS=19E8 IP=0100 NV UP EI PL NZ NA PO NC
19E8:0100 8B1E3412 MOV BX,[1234] DS:1234=0000
It works with most instructions:
mov reg,mem; mov mem,reg; add reg,mem; add mem,reg; add mem,immed;
push mem; shr mem,cl
and all similar ones, but *NOT* with
MOV [nnnn],AX (or AL, or EAX)
using the short three-byte opcode variant (A2 or A3 + nnnn); the long
four-byte variant, which is normally not generated by assemblers,
correctly shows the DS:nnnn contents.
For possible future releases :-) it could be also useful to show
while tracing:
* the contents of DS:SI and/or ES:DI for string intructions
* value to be popped from stack for POP
* return address to be popped for RET
* byte values also as ASCII characters
but it's only wishlist...
Another thing: DEBUG doesn't recognize opcode variants starting from
82 for instructions like add byte ptr [nnnn],nn. Probably no assembler
generates them, but they are executed by (all?) processors.
And more general, for many invalid opcodes it's easy to determine
whether the opcode is 1-, 2-, 3-byte or more, and what addressing mode
it uses; so it could be useful to display, e.g., 4-byte invalid opcode
as "DB nn,mm,pp,qq" or even, "??? WORD PTR [SI+qqpp]" instead of
"DB nn", but there are arguments for and against.
A more practical missing feature is interception of Invalid Opcode (6)
and maybe General Protection (13) exceptions.
Anyway, MS-DOS DEBUG is still far behind...
Michal
- Raw text -