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 STRIDE_ENABLED (or srIMON in 3.0.01xx or older releases) preprocessor directive 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 -DSTRIDE_ENABLED=1 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 public interface (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 STRIDE Runtime. 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.