Daniel Janus’s blog
DOS debugging quirk
6 April 2014
While hacking on Lithium, I’ve noticed an interesting thing. Here’s a sample DOS program in assembly (TASM syntax):
100h N equ 2 start: mov bp,sp mov ax,100 mov [bp-N],ax mov cx,[bp-N] cmp cx,ax jne wrong mov dx,offset msg jmp disp wrong: mov dx,offset msg2 disp: mov ah,9 int 21h mov ax,4c00h int 21h msg db "ok$" msg2 db "wrong$" end starttiny org
If you assemble, link and then execute it normally, typing
prog in the DOS command line, it will output the string “ok”. But if you trace through the program in a debugger instead, it will say “wrong”! What’s wrong?
The problem is in lines 10-11 (instructions 3-4). Here’s what happens when you trace through this program in DOS 6.22’s
Note how in instruction 3 (actually displayed as the second above) we set the word
100. When about to execute the following instruction, we would expect that word to continue to hold the value
100, because nothing which could have changed that value has happened in between. Instead, the debugger still reports it as
0x0D8A, as if instruction 3 had not been executed at all — and, interestingly, after actually executing this instruction,
CX gets yet another value of
Normally, thinking of DOS
.COM programs, you assume a 64KB-long chunk of memory that the program has all to itself: the code starts at
0x100, the stack grows from
0xFFFE downwards (at any given time, the region from
0xFFFE contains data currently on the stack), and all memory in between is free for the program to use however it deems fit. It turns out that, when debugging, it is not the case: the debuggers need to manipulate the region just underneath the program’s stack in order to handle the tracing/breakpoint interrupt traps.
I’ve verified that both DOS’s DEBUG and Borland’s Turbo Debugger 5 do this. The unsafe-to-touch amount of space below SP that they need, however, varies. Manipulating the N constant in the original program, I’ve determined that DEBUG only needs 8 bytes below SP, whereas for TD it is a whopping 18 bytes.