Browse Prior Art Database

Code Instrumentation for Error Injection

IP.com Disclosure Number: IPCOM000122358D
Original Publication Date: 1991-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 134K

Publishing Venue

IBM

Related People

Gregg, LE: AUTHOR [+3]

Abstract

Described is a simple method of simulating error return codes from microcode routines. The method allows error injection to be done simply and without the intimate knowledge of the microcode being tested required by prior techniques.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Code Instrumentation for Error Injection

      Described is a simple method of simulating error return
codes from microcode routines.  The method allows error injection to
be done simply and without the intimate knowledge of the microcode
being tested required by prior techniques.

      The technique is to include in the code modules some
"instrumentation" points designed expressly for error injection.
Very simply the idea is to provide some "fixed" addresses which can
be used to stop execution.  These addresses would not vary with
different versions of the code.  Therefore, once a test procedure was
developed, it would work on any version of the code without
modification.

      Now, to make the operation of this tool more useful, it is also
desirable to limit the times the fixed address is reached.  Ideally,
only the one case of interest would execute at the fixed address, but
that is not quite possible.  What is possible with minimal work is to
limit the number of times the fixed address is reached.  In the
initial implementation, selection based on the device being utilized
and the type of operation being performed was allowed.  Other
criteria could easily be introduced if further granularity is needed.

      In addition to causing execution to be at a fixed address, it
is also helpful to provide a small amount of data - also at a fixed
address - to make the error injection process easier.  This data
consists of some of the information which will be required to force a
particular error.  An example is the address of the command about to
be sent to hardware.

      To implement this technique additional code was added at some
points of interest in the code.  In one case this meant before and
after commands were sent to the hardware, and when responses were
received from the hardware.  The first case allows modification of
the command being sent, while the last case obviously allows
modification of the response received back.

      To minimize the run-time performance degradation at each of
these points the first thing done is a simple test of a bit to see
if the instrumentation is active.  If not, there is no additional
code execution for the instrumentation function.

      If the instrumentation is active, then an additional test is
done to determine if instrumentation is active for the particular
sub-function about to be done.  Again, if not, there is no further
execution for the instrumentation.

      Finally, if instrumentation is active for this sub-function, a
few data items are stored - at fixed addresses - and then execution
transfers to a fixed address. At that fixed address there is only one
instruction - and that is a transfer right back to where we came
from.  (This is done as a subroutine call to a routine which consists
of only 1 instruction - return.)

      It is assumed that when this fixed address is reached an
emulator or other d...