Difference between revisions of "Studio:Integrating the Intercept Module (IM)"

From STRIDE Wiki
Jump to: navigation, search
(IM Resource Requirements)
(Starting the IMStubRead thread)
Line 66: Line 66:
  
 
=== Starting the IMStubRead thread ===
 
=== Starting the IMStubRead thread ===
The IM must be started ''after'' the Runtime and Transport has 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.
+
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.
  
 
This code snippet, based on using the POSIX call pthread_create() to start a task (your OS may use a different call), demonstrates how to initialize the PAL and the Runtime, start the IM, then become the Runtime message processing loop.  Note that this code assumes that it will become the Runtime thread's message processing loop (because srThread() will never return).  The comments note that this could instead create a second task for the Runtime and return.
 
This code snippet, based on using the POSIX call pthread_create() to start a task (your OS may use a different call), demonstrates how to initialize the PAL and the Runtime, start the IM, then become the Runtime message processing loop.  Note that this code assumes that it will become the Runtime thread's message processing loop (because srThread() will never return).  The comments note that this could instead create a second task for the Runtime and return.

Revision as of 17:04, 1 February 2008

Intercept Module Files and their purpose

The Intercept Module is generated by STRIDE Studio for the specific set of function interfaces you select. Three files are created, each prepended with the name of the Intercept Module that you gave it when it was created:

  • The Intercept Module source file (imnameIM.c or imnameIM.cpp)
    This file contains the code that allows the remoting of functions so that they can be accessed by the Target and Host.
  • The Delegate Mangling header file (imnameIM.h)
    This file must be included in all of your C files that are using Delegates (Dynamic or Tracing). It contains macros that will mangle the appropriate function names so that they can be intercepted and routed through the IM. When used, it must be the last file #include'd in the source. Also, it is only required if the C file uses Delegates. Stubs and Proxy functions do not require this file
  • The IM Entry point header file (imnameIMEntry.h)
    This file contains the prototypes for the external entry points into the IM. It is needed only by the function that starts the IM Stub Read Thread.

These filenames are all prepended by the name you give the IM when it is generated. For example, if you call the IM "MyProject", then the resulting filenames will be "MyProjectIM.c", "MyProjectIM.h", and "MyProjectIMEntry.h".

Configuring and generating an Intercept Module

You can either generate the IM via STRIDE Studio's Intercept Module Wizard, or you can utilize scripts to automatically configure and generate the IM files. These files will contain Studio-based configuration definitions. In addition, the script used for configuration will denote in which context the IM runtime functions are to be executed.

The script can execute automatically so that the Intercept Module is built as part of the test automation framework, as shown in the following example. The IM generation script should open a Studio workspace, optionally compile the workspace and save the database (if needed), then configure and create the IM as shown in the following Perl example:

 # Compile and save the workspace database
 $main::studio->Workspace->CompileAll();
 $main::studio->Workspace->Save();
 
 # Intercept Module (IM) name and path constants
 my $IM_FILE_NAME = "MyProject";
 my $IM_LOCATION_PATH = $main::studio->Workspace->Path;
 
 # Create a reference to the workspace IM object
 my $IM = $main::studio->Workspace->Intercept;
 
 # Local variables
 my ($i, $fx);
 
 # Reset all of the IM configuration settings to off and
 # reset the delegate group Id's to their default name.
 $IM->Reset();
  
 # Setup the IM name and path
 $IM->{Name} = $IM_FILE_NAME;
 $IM->{Path} = $IM_LOCATION_PATH;
  
 # For each interface in the IM collection
 for ($i=0; $i < $IM->Count(); $i++)
 {
     # reference the ith interface;
     $fx = $IM->Item($i);
  
     $fx->{Stub} = 1;               # configure as stub
                                    # and delegate
     $fx->Delegate->{Owner} = 1;    # mangle from owner's perspective
     $fx->Delegate->{Explicit} = 1; # implicit name mangling
     $fx->Delegate->{Dynamic} = 1;  # enable dynamic interception
 }                                 
  
 # Create IM files.
 $IM->Create();

Note in the above script how the IM name and output directory were defined. In this case, all three files are created in the same directory as the STRIDE workspace. The resulting Intercept Module file must then be compiled and built with the rest of your target code.

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 thread

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.

This code snippet, based on using the POSIX call pthread_create() to start a task (your OS may use a different call), demonstrates how to initialize the PAL and the Runtime, start the IM, then become the Runtime message processing loop. Note that this code assumes that it will become the Runtime thread's message processing loop (because srThread() will never return). The comments note that this could instead create a second task for the Runtime and return.

 #include <stdio.h>
 #include <pthread.h>
 #include "MyProjectIMEntry.h"    // The STRIDE IM Entry Point header file
 
 extern palBOOL palInit();            // The PAL initialization routine
 extern void MyProjectIMStubThread(); // The IM message handler ("MyProject" is the IM name)
 
 /* A function to start the STRIDE elements.   */
 /* This function never returns if successful. */
 void STRIDEstartup ()
 {
     static pthread_t thr;
 
     /* Initialize the PAL. A return value of srTRUE means it succeeded. */
     /* (This will open the transport to the host) */    
     if (palInit() == srTRUE)
     {
         /* Initialize the runtime */
         srInitialize (srTRUE, 5000);
 
         /* Start the IM message handling thread. */
         pthread_create (&thr, NULL, (void *(*)(void *)) MyProjectIMStubThread, 0);
 
         /* Become the runtime thread - this never returns. */
         /* Alternatively, this could also be spawned as a  */
         /* separate thread using pthread_create().         */
         srThread();
     }
 }