Helpful Features in a Debugger

[Jerome H. Fine]

 >On Monday, February 22nd, 2016 at 15:22:55 +0100, Pontus Pihlgren wrote:

>>On Mon, Feb 22, 2016 at 09:08:56AM -0500, Jerome H. Fine wrote:
>  
>
>>A number of other ideas are as follows:
>>
>>(a)  During a multi-step sequence, stop the sequence when the
>>     stack has more then a specified number of words of increase
>>     or decrease - each specified separately
>>(b)  Set the address range within which the stack must remain
>>      or a multi-step sequence is stopped which is similar to (a),
>>      but expressed differently
>>(c)  Set the address range within which the program counter
>>      must remain or a multi-step sequence s stopped
>>
>I can see how all of these can be usefull. Perhaps a possibility of 
>stopping after a given number of jumps?
>
I was thinking of that as well.  The question is if conditional branch 
instructions
should also be included as opposed to an actual jump.  With regard to 
conditional
branches, the choice could be to stop only if the branch is taken.

Note that calling and returning from a subroutine, while not explicitly
handled, is managed by controlling the number of words added to
or removed from the stack.

>>Also possible to be checked are specified values that registers
>>have, or don't have, which stop a multi-step sequence.  Checks
>>on memory locations can also be included.
>>
>Watching memory locations for changes or agains boolean expressions is 
>very useful.
>
Agreed.  In the past, most of my debugging tends to center on the
newest code which has been added in order to determine if the
newest code is correct or not.  In most cases, the normal method
is to step through one instruction at a time and to then determine
if the assumptions made were correct and if the expected result
occurs.  For these situations, single stepping is the only method
that seems to be well suited and with a step count of one, no
other conditions are required to stop.

However, when there is a undetermined bug, just finding what and
where the problem is occurring usually takes 90% of the effort.
Under this type of situation, additional stopping conditions should
be helpful.

>>And a record of which instructions were executed by saving
>>the program counter addresses in a circular buffer allows the
>>user to check for unexpected execution of certain parts of
>>the code.
>>
>A collegue used a similar tool that recorded _everything_ that happened 
>in a CPU under testing. So he could step back and forth in program time 
>and inspect registers and memory. Very useful and very expensive 
>apparently.
>
The major difficulty is that far too much useless information is
gathered in such an approach since it is almost impossible to
know in advance what is really necessary.  Then, writing the
code for that sort of approach is also extremely difficult.  So
while saving only the program counter addresses is rarely
sufficient, at least it will usually help to locate where the problem
occurred.

>>All suggestions and comments are much appreciated!!!!!!!!!
>>
>I allways use "run to" which is just a temporary breakpoint. Useful and 
>probably easy to implement.
>
That can probably be done quite easily.  I will need to check.

One of the difficulties I am having with the actual implementation
is that almost all of the code and data is in multiple PAR1 areas
of memory since I am using the Mapped RT-11 Monitor, RT11XM.
Thus far, there are 4 * 8192 Byte PAR1 windows of memory, each
of which communicates only via a very limited number of words in
Low Memory.  The use of PAR1 addresses is standard in RT-11
within a device driver, so that part of the solution is good.  In fact,,
one of the most important challenges during the enhancement was to
reduce the number of words in Low Memory as much as possible.
However, as a consequence, the data which is required to determine
what needs to be done while the code is executing in one of the
PAR1 windows is often in a different PAR1.  Unfortunately, the
required communication always seems to need a few extra words
in the first PAR1 and at this point the first PAR1 is totally full -
which makes communication rather difficult.  Thus far, a solution
has eventually been found.

Jerome Fine