System/161 supports remote gdb debugging directly into the simulator. The simulator acts like an in-circuit emulator (ICE), only more so, so that you can debug without any interference whatsoever with the debugged code. Even timing is unaffected.
To do this, you need a copy of gdb compiled for the same processor that System/161 is simulating, and that understands the ELF kernel file format loaded by System/161. To use the Unix-domain sockets method shown below, you need a patch to gdb; without that you are restricted to using Internet-domain sockets and you can't necessarily control who can connect. A suitable gdb configuration is provided for OS/161.
Run gdb as you normally would:
gdb kernel
After it finishes loading, attach to System/161 by typing this into gdb:
target remote unix:.sockets/gdband gdb will connect up to the copy of System/161 you have running in the same directory and you can start debugging. (You can debug one in another directory by specifying the right path to its socket.)
Since this is a painful thing to type every time you want to debug, we recommend you create a shortcut for it. Put the following in a file called .gdbinit in the same directory you're working in. (gdb runs this file when you start it up.)
define db target remote unix:.sockets/gdb endThen you can connect up to System/161 for debugging just by running gdb and typing "db".
If you give System/161 the -w option, it will stop and wait for a debugger connection before it runs anything at all. This allows you to start debugging from the very beginning of kernel initialization.
Theoretically everything you can do with gdb normally should work with gdb connected this way. In practice, there are probably some problems. Bring them to the attention of the course staff and we'll see if we can get them fixed.
When System/161 is running, if you type ^G (control-G) into its window, it will immediately stop in gdb (if gdb is attached) or wait for a gdb connection (if gdb is not attached).