I know of only one example of a debugger which supports
a Program Counter History Log.
I am in the process of adding a Program Counter History Log
to the System Debugger in RT-11 on a PDP-11. I would
appreciate a few suggestions from anyone who has any
experience with a debugger program which supports
Program Counter History Logging.
For users who are not familiar with PDP-11 hardware,
the primary interface is a serial terminal, usually with
9600 baud these days (don't laugh - I first started on
a PDP-11 around 1975 over a 300 baud modem), with
a screen of 24 lines by 80 columns. There are a probably
a VERY, VERY few systems which use VT420 terminals
which can support 48 lines, but which are probably rarely,
if ever used with other than 24 lines by 80 columns. From
my point of view, the primary considerations are the lack
of both speed (9600 baud takes seconds to fill a full screen)
and available screen space to display more than about 200
addresses from the History Log Buffer (at 10 addresses
per line). While I normally use the Ersatz-11 Emulator for
the PDP-11 which provides me the possibility of using
screens of 50 lines, I suspect that I am presently the ONLY
person to interact with RT-11 using a screen of this many
lines, let alone the speed of the screen which is so fast that
the time between SCROLL and NOSCROLL is usually
a dozen lines of output to the screen. At 9600 baud, the
SCROLL vs NOSCROLL time delay is only a few
dozen characters at most, certainly less than one line
of output to the screen in almost all cases.
The only experience I have with a debugger which has a
History Log is with a 64 word buffer of addresses for
the 64 immediately previous instructions. While this is
often sufficient to at least pinpoint the general location of
where the program stopped, it was often insufficient to
locate where the problem started.
For those who have direct PDP-11 experience, the
following information might also be useful. At present,
there are two buffers which can be displayed:
(a) A buffer with 40 of the last interrupt entries to SD:
which are composed of 5 words each:
- Program Counter Address from the Stack
- Program Status Word from the Stack
- Word (instruction?) at that Address
- Word (instruction?) at the Previous Address
- Control Word which is used by SD: (PROSNG)
(b) A buffer with the last 1000 Addresses of the last
1000 instructions that have been executed
The current logic in the code to save each instruction
address in the 1000 word buffer ONCE and ONLY
once uses all five of the above values.
There seems no point in displaying all 1000 addresses
since only about 200 can stay on the screen and it takes
too long in any case. However, just how useful are the
past 1000 addresses as an aid in debugging? Since it
takes no additional time for a larger circular buffer over
a smaller circular buffer (in fact maybe a larger buffer
is insignificantly faster) and there is memory available,
I opted for the largest buffer that was reasonable
The other buffer with the 5 word entries entries for
the last 40 interrupts will be used when there are any
questions about the exact details of any interrupt with
respect to a user having set a Breakpoint or any other
logic errors in the debugger in general and specifically
when adding addresses to the 1000 word history log.
NOW finally, here are my questions.
Are there any suggestions as to how many previous
instructions are needed to usually be helpful to have a
log for when a program has a problem? Also, would
it be useful to have the first word (two bytes) of the
instruction as well as the address in order to identify
the actual instruction or is the address almost always
sufficient? On the PDP-11 with instructions being
1, 2 or 3 words, it is totally unlikely that having the
addresses of the previous instructions would ever
allow a user to confuse which code was previously
executed unless two variants of almost identical code
had been purposely constructed so as to confuse the
user. This could occur when two overlays use the
same addresses to execute that code, but it is almost
impossible to happen by chance and even it it did,
an extra NOP could simply shift the code for one
of the variants so as to avoid the confusion.
Jerome Fine