Studio:Integrating the Intercept Module (IM)

About Intercept Modules

Intercept Modules allow remote function calls across hardware (e.g., processor or machine) or software (operating system) platform boundaries. Intercept Modules are target-based components that are created as a step in the STRIDE build process. The Intercept Module, or IM, is created based on selected interfaces or test units that have been "captured", or identified through a subset of SCL pragmas that tag interfaces as candidates for remote function calls. Once created, the generated code is then compiled, linked and run along with the target application.

Activating the Intercept Module

Compiling the IM

To compile the IM, you must define the macro srIMON when you compile the IM.c file or any file that includes one of the headers. This "turns on" the intercept feature. For example:

 cc -c -IC:\STRIDE\inc -DsrIMON MyProjectIM.c

Notice that the IM.c and IMEntry.h files reference header files in the STRIDE installation directory. The build must include this directory when compiling either of these files. The Delegate (IM.h) header file does not have any dependencies on this directory.

IM Resource Requirements

The Intercept Module is usually run as a separate task, and therefore has some resource requirements that are in addition to those of the Runtime and the PAL. One of these is the task resource itself. Another is space for the task stack.

The required task stack size if difficult to predict since it is dependent on the underlying system and on the data that is passed through function arguments. A stack size between 2-4K would be a good starting point.

Starting the IMStubRead threads

The IM must be started after the Runtime and Transport have been initialized, but before any intercepted calls can be made. Failure to do this before making an intercepted call can crash or hang the target.

Look at any of the prepackaged SDKs for examples of integrating your application.