Setting breakpoints

Executing a program under a debugger is of no great use without breakpoints. Here is the simplest way in which they can be set.

We can do even better than that. Try

Everything which follows :b on the input line will be stored and executed later on when the breakpoint is hit. Multiple commands are separated by semicolons. By the way, you may use semi-colons for immediate requests too.

Breakpoints also can have counts. Using as an example unexpand.tos, and a fragment of its disassembled code shown in a previous section, we may set a breakpoint

in a main loop of this program, just before fgetc() is called. With this count an execution will stop only for every third character to be accepted.

Setting a breakpoint on the top of an existing one is allowed and it will simply cause a replacement — changing possibly a count and commands to execute. A list of all current breakpoints, with their counts and associated commands, is produced by the $b request. Information shown at the bottom of this list will be explained later.

It is not the best idea to set a breakpoint somewhere between two program instructions. Nothing terrible will happen immediately, but your debugging run may end up prematurely amid an utter confusion. Sometimes it is possible to restart a wayward program by writing a needed address directly into a program counter with a address>pc request, but this is not guaranteed to work. It is also advisable to keep breakpoints on an execution path. They are a limited resource and there is no point wasting it.