On-line Debugging Tool (ODT) was used to describe several debugger
programs developed for Digital Equipment Corporation
(DEC) hardware. Various operating system
s including OS/8
, and RSTS/E
implemented ODT as did the firmware
console of all of the LSI-11
-family processors including the 11/03, 11/23/24, 11/53, 11/73
, and 11/83/84.
The debugger allowed access to memory using octal
addresses and data. Within the software system
s, the debugger accessed the process's address space. DEC's line of PDP-11 processors did not implement virtual memory
, from an operating system perspective, but instead worked in a fixed address space, which was mapped into a unified view of the program's address space, using an Active Page Register (APR). An APR could map the program's RAM in increments of 4K 16-bit words, to a maximum of 32K. In other words, an APR could map 8 segments of RAM, each limited to 4K. Because of this structure, the maximum RAM an APR was able to map was 32K 16-bit words. In the case of RSTS/E, this usually meant that a Runtime System, or RTS, mapped to the upper portion of the address space and a user program resided in the lower portion of the address space. The RTS provided code to support access to the Operating System, on behalf of the user program; the RTS itself stored any of its non-static data in the address space of the user program, because the RTS was typically read-only. The operating system loaded a single copy of the RTS and this was mapped to any user program that required that RTS. The APR would be set to map the RTS into the upper portion of the program's address space, in 4K increments. So the BASIC Plus RTS (for the Basic+ Programming Language) typically mapped 16K to itself and the user program was mapped, in 4K increments, in the lower 16K. The RT11 RTS occupied 4K so a user program, like the RT11-based Peripheral Interchange Program (PIP), could expand to a maximum of 28K.
ODT could be used to "patch" binary modules, like an RTS, without requiring the re-compilation of the binary's source.
The firmware console implementation accessed physical memory
ODT is a non-symbolic debugger and implements similar functionality to Advanced Debugger
(adb) on Unix
Console ODT replaced the lights and switches console of many of the earlier processors.
Access to console ODT is obtained either from power up (with appropriate power up mode selected), by the execution of a HALT instruction in kernel mode, or by use of the front panel halt switch or button.
@1000/ xxxxxx 112737
001002 xxxxxx 101
001004 xxxxxx 177566
001006 xxxxxx 137
001010 xxxxxx 1000
This deposits the program
MOVB 'A', @#177566 ; Move 'A' into console transmit register
JMP @#1000 ; Jump back to start
The deposit to the PC rogram Counter sets the PC to the start of the program and the deposit to the PSW rogram Status Wordlocks out interrupts.
The effect of this will be to write a stream of "A" to the console. As there is no check for transmitter ready, it is highly probable that a large number of garbage characters will be displayed.
The RSX-11M-Plus ODT is essentially a superset of all other ODT implementations.
ODT is implemented as code that is linked with a task using the Task Builder /DA switch.
Once any task built with ODT is run ODT is invoked on entry.
The underscore is the standard ODT prompt.
Addresses in the ODT debugger are 16 bit addresses in the mode in which ODT is operating, not the physical addresses used with console ODT.
OS/8 Octal Debugging Technique
The PDP-8's OS/8 operating system's ODT command
[Reference manual DEC-D8-COCO-D, ODT-8, Dec. 1967 ] invoked its ''Octal Debugging Technique'' tool.
As with the subsequent PDP-11 ODT programs, it was non-symbolic, and it could examine or modify memory, and also set breakpoints.
* Dynamic Debugging Technique (DDT)
* Executive Debugging Technique (XDT)
Category:Digital Equipment Corporation