STRIDE Build Tools: Difference between revisions
No edit summary |
|||
(34 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
__NOTOC__ | |||
[[image:STRIDE Build Process1.jpg|thumb||STRIDE Build Process Overview]] | |||
The STRIDE Build Tools are a set of command line utilities that perform the Stride compile/build process on a supported platform, which may be easily invoked through makefiles or similar build utilities (eg. ANT). | |||
The Build Tools consist of the following utilities: | |||
The | # [[s2scompile|The STRIDE Compiler (s2scompile)]]<br> | ||
# [[s2sbind|The STRIDE Database Binder (s2sbind)]]<br> | |||
# [[s2sinstrument|The STRIDE Instrumentation Generator (s2sinstrument)]] | |||
Refer to [[Build Integration]] on how to obtain and integrate them in your environment. | |||
=Compiling multiple files= | |||
In this scenario, the '''s2scompile''' utility is invoked with a list of header files, containing SCL, each to be compiled a resulting intermediate (.meta) file: | In this scenario, the '''s2scompile''' utility is invoked with a list of header files, containing SCL, each to be compiled a resulting intermediate (.meta) file: | ||
s2scompile –I" | s2scompile –I"path/to/include" –DN=100 file1.h file2.h | ||
=Database Binding= | |||
Here, the '''s2sbind''' utility is invoked with a list of .meta files to be bound into the specified database (.sidb) file: | Here, the '''s2sbind''' utility is invoked with a list of .meta files to be bound into the specified database (.sidb) file: | ||
s2sbind –-starting_suid=123 test.sidb file1.meta file2.meta | s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta file2.h.meta | ||
=Intercept Module Generation= | |||
==Single Intercept Module== | |||
===Pre-build Instrumentation=== | |||
In this scenario, the compilation, binding and instrumentation are done before the user’s build. Here, '''s2scompile''' is called first, then '''s2sbind''', and finally '''s2sinstrument''': | In this scenario, the compilation, binding and instrumentation are done before the user’s build. Here, '''s2scompile''' is called first, then '''s2sbind''', and finally '''s2sinstrument''': | ||
=====In-build Prototyping with Post-build Implementation | s2scompile –I"path/to/include" –DN=100 file1.h file2.h | ||
s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta file2.h.meta | |||
s2sinstrument –-im_name=test -–mode=S(f1) -–mode=P(f2) test.sidb | |||
===In-build Prototyping with Post-build Implementation=== | |||
Here, the compilation, binding and Intercept Module(IM) prototyping (header files only generation) are done incrementally. Note that at the second bind step during prototyping, '''s2sbind''' is given an option specifying the existing database to merge with. Also note that '''s2sinstrument''' is called the first two times with the "prototype" option specified and then finally is called with the "implement" option for code generation: | Here, the compilation, binding and Intercept Module(IM) prototyping (header files only generation) are done incrementally. Note that at the second bind step during prototyping, '''s2sbind''' is given an option specifying the existing database to merge with. Also note that '''s2sinstrument''' is called the first two times with the "prototype" option specified and then finally is called with the "implement" option for code generation: | ||
s2scompile –I"path/to/include" –DN=100 file1.h | |||
s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta | |||
s2sinstrument –-im_name=test –-prototype=p1 -–mode=S(f10,f11) test.sidb | |||
s2scompile –I"path/to/include" –DN=100 file2.h | |||
s2sbind –-input_database=test.sidb --output=test.sidb file2.h.meta | |||
s2sinstrument –-im_name=test –-prototype=p2 -–mode=P(f20,f21) test.sidb | |||
s2sinstrument –-im_name=test –-implement -–mode=S(f10,f11) -–mode=P(f20,f21) test.sidb | |||
==Multiple Intercept Modules== | |||
The compilation, binding and Intercept Module(IM) generation (headers and source) are done incrementally. For each component of the user’s build just a subset of SCL files are compiled, bound to a database (merged into the previously created database) and an IM generated for a set of interfaces defined in those SCL files. | The compilation, binding and Intercept Module(IM) generation (headers and source) are done incrementally. For each component of the user’s build just a subset of SCL files are compiled, bound to a database (merged into the previously created database) and an IM generated for a set of interfaces defined in those SCL files. | ||
This example shows how this can be accomplished. Notice that a unique name is specified for each IM when s2sinstrument is called: | This example shows how this can be accomplished. Notice that a unique name is specified for each IM when s2sinstrument is called: | ||
s2scompile –I"path/to/include" –DN=100 file1.h | |||
s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta | |||
s2sinstrument –-im_name=test1 -–mode=S(f1) test.sidb | |||
s2scompile –I"path/to/include" –DN=100 file2.h | |||
s2sbind –-input_database=test.sidb --output=test.sidb file2.h.meta | |||
s2sinstrument –-im_name=test2 -–mode=P(f2) test.sidb | |||
==Partial Intercept Module== | |||
By default, the instrumentation of a referenced database generates IM code for all functions. If no '''--mode''' option is specified the generate IM code would be all Stub. | |||
s2sinstrument test.sidb | |||
The user can control that default behavior by passing explicitly '''--default_mode''' option. For example to generate Proxy for all functions except for function f3: | |||
s2sinstrument --default_mode=P --mode=(f3) test.sidb | |||
In certain cases it might be desirable to generate partial intercept module - IM code for only specific set of functions. That requires disabling the default behaviour and listing the requested functions with '''--mode''' option. For example to generate Proxy IM code for only functions f1 and f2: | |||
s2sinstrument --default_mode=# --mode=P(f1,f2) test.sidb |
Latest revision as of 14:43, 4 July 2015
The STRIDE Build Tools are a set of command line utilities that perform the Stride compile/build process on a supported platform, which may be easily invoked through makefiles or similar build utilities (eg. ANT).
The Build Tools consist of the following utilities:
- The STRIDE Compiler (s2scompile)
- The STRIDE Database Binder (s2sbind)
- The STRIDE Instrumentation Generator (s2sinstrument)
Refer to Build Integration on how to obtain and integrate them in your environment.
Compiling multiple files
In this scenario, the s2scompile utility is invoked with a list of header files, containing SCL, each to be compiled a resulting intermediate (.meta) file:
s2scompile –I"path/to/include" –DN=100 file1.h file2.h
Database Binding
Here, the s2sbind utility is invoked with a list of .meta files to be bound into the specified database (.sidb) file:
s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta file2.h.meta
Intercept Module Generation
Single Intercept Module
Pre-build Instrumentation
In this scenario, the compilation, binding and instrumentation are done before the user’s build. Here, s2scompile is called first, then s2sbind, and finally s2sinstrument:
s2scompile –I"path/to/include" –DN=100 file1.h file2.h s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta file2.h.meta s2sinstrument –-im_name=test -–mode=S(f1) -–mode=P(f2) test.sidb
In-build Prototyping with Post-build Implementation
Here, the compilation, binding and Intercept Module(IM) prototyping (header files only generation) are done incrementally. Note that at the second bind step during prototyping, s2sbind is given an option specifying the existing database to merge with. Also note that s2sinstrument is called the first two times with the "prototype" option specified and then finally is called with the "implement" option for code generation:
s2scompile –I"path/to/include" –DN=100 file1.h s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta s2sinstrument –-im_name=test –-prototype=p1 -–mode=S(f10,f11) test.sidb
s2scompile –I"path/to/include" –DN=100 file2.h s2sbind –-input_database=test.sidb --output=test.sidb file2.h.meta s2sinstrument –-im_name=test –-prototype=p2 -–mode=P(f20,f21) test.sidb
s2sinstrument –-im_name=test –-implement -–mode=S(f10,f11) -–mode=P(f20,f21) test.sidb
Multiple Intercept Modules
The compilation, binding and Intercept Module(IM) generation (headers and source) are done incrementally. For each component of the user’s build just a subset of SCL files are compiled, bound to a database (merged into the previously created database) and an IM generated for a set of interfaces defined in those SCL files. This example shows how this can be accomplished. Notice that a unique name is specified for each IM when s2sinstrument is called:
s2scompile –I"path/to/include" –DN=100 file1.h s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta s2sinstrument –-im_name=test1 -–mode=S(f1) test.sidb
s2scompile –I"path/to/include" –DN=100 file2.h s2sbind –-input_database=test.sidb --output=test.sidb file2.h.meta s2sinstrument –-im_name=test2 -–mode=P(f2) test.sidb
Partial Intercept Module
By default, the instrumentation of a referenced database generates IM code for all functions. If no --mode option is specified the generate IM code would be all Stub.
s2sinstrument test.sidb
The user can control that default behavior by passing explicitly --default_mode option. For example to generate Proxy for all functions except for function f3:
s2sinstrument --default_mode=P --mode=(f3) test.sidb
In certain cases it might be desirable to generate partial intercept module - IM code for only specific set of functions. That requires disabling the default behaviour and listing the requested functions with --mode option. For example to generate Proxy IM code for only functions f1 and f2:
s2sinstrument --default_mode=# --mode=P(f1,f2) test.sidb