Internal interfaces in the OBC debugger

From Spivey's Corner
Jump to: navigation, search


The debugger is connected by a two-way pipe (actually a local network socket) to the debugging monitor that is running the bytecode program. When the program is stopped, the debugger can access its memory via commands sent over the pipe. Before the program starts, the monitor extracts symbol information from the bytecode file, and uses it to send absolute addresses (in the address space of the monitor process) of each procedure and variable to the debugger.

There is a module Procio that is responsible for all interaction with the debugging monitor.

Symbol table

I've provided a module Binary to store the symbol information that is transmitted by the monitor before the program starts. This module maintains a number of mappings between symbol names (like "Main.Fac") and absolute addresses in the address space of the monitor. If the program has been compiled with the -pl flag to enable line numbers, then the debugger will also know the code address of each line.

Debugging info

In addition to the mapping between symbols and binary addresses, the debugger also has access to the compiler's information about each module of the program, stored in the '.k' file. The debugger shares the compiler's module for reading this information, and so also the compiler's internal representation for definitions, types and environments. The debugger module named Info is responsible for maintaining a table of this information.

Source code

There's a module called Source that is responsible for finding the source text of the program that's being debugged, and locating lines in the source from their line numbers. At the moment, the entire contents of each source file is stored in an array of strings. If we needed a version of the debugger that occupied less memory, we could re-implement the module, but for now this implementation is good enough.