STRIDE Build Tools: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
No edit summary
 
(61 intermediate revisions by 5 users not shown)
Line 1: Line 1:
Top level page for Build Tools topic.
__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).


PAL pdf document:
The Build Tools consist of the  following utilities:
[http://www.s2technologies.com/wiki/images/e/e3/S2sPAL.pdf]
# [[s2scompile|The STRIDE Compiler (s2scompile)]]<br>
[http://www.s2technologies.com/pdf/S2_Executive_Overview.pdf]
# [[s2sbind|The STRIDE Database Binder (s2sbind)]]<br>
# [[s2sinstrument|The STRIDE Instrumentation Generator (s2sinstrument)]]


Media Tag:
[[Media:s2sPAL.pdf]]


Image Tag:
Refer to [[Build Integration]] on how to obtain and integrate them in your environment.
[[Image:ProductionBuildEFS.jpg]]


==Build Tools==
=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:


===Commandline Utilities:===
    s2scompile –I"path/to/include" –DN=100 file1.h file2.h


#The STRIDE compiler (s2scompile.exe)
=Database Binding=
Here, the '''s2sbind''' utility is invoked with a list of .meta files to be bound into the specified database (.sidb) file:


#The STRIDE database binder (s2sbind.exe)
    s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta file2.h.meta


#The STRIDE instrumentation generator (s2sinstrument.exe)
=Intercept Module Generation=


=== The '''s2scompile''' Component ===
==Single Intercept Module==


==== Syntax and Options ====
===Pre-build Instrumentation===
'''s2scompile [options] scl_file1 [scl_fileN]'''
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''':


The s2sCompile utility will compile a set of scl files (C/C++ source files with SCL pragmas) and produce a meta file for each (assuming that compilation is successful). All warnings and errors that occur during the compilation are written to the standard output device. The compilation for a particular file is considered successful if no errors occur. Otherwise it is unsuccessful. Unsuccessful compilations do not yield .meta files.
    s2scompile –I"path/to/include" –DN=100 file1.h file2.h
Options are validated and any incorrect options diagnosed will result in compilation process failure.
    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:


{| border="1" cellspacing="0" cellpadding="10" style="align:left;background-color:#ffffcc;" 
    s2scompile –I"path/to/include" –DN=100 file1.h
!width="200pt"|'''Option'''
    s2sbind –-starting_suid=123 --output=test.sidb file1.h.meta
!width="500pt"|'''Description'''
    s2sinstrument –-im_name=test –-prototype=p1 -–mode=S(f10,f11) test.sidb
|-
| --preprocess
| Do preprocessing only. Write preprocessed text file to the output. The
output file suffix is automatically changed to ".i".
|-
| --dependencies
| Do preprocessing only. Instead of the normal preprocessing output, generate
on the preprocessing output file a list of dependency lines suitable for
input to the UNIX make program.
|-
| --no_line_commands
| Same as –preprocess except that line number information is removed from the preprocessed output files.
|-
| --c++
| Enable compilation of c++.
|-
| --c
| Enable compilation of C (specifically C89). This is the default.
|-
| --include_directory=<dir>
| rowspan="3"| Add dir to the end of the list of directories searched for #includes.
|-
| --sys_include=<dir>
|-
| -I<dir>
|-
| --define_macro=name[(parm-list)][=def]
| rowspan="2"| Define macro name as def. if "= def" is omitted, define name as 1.
|-
| -Dname[(parm-list)][=def]
|-
| --accept_zero_length_array
| Accept zero length arrays declared in structs
|-
| --no_warning
| Suppress all warnings in the compilation phase.
|-
| --compatibility=<string>
| Vendor compatibility mode. String can be "microsoft", "generic" or "gnu". Default is "generic". When "Microsoft" is set, the compiler supports a number of extensions to the C or C++ language that are compatible with the Microsoft family of compilers. "gnu" - instructs the compiler to support language extensions compatible with the Gnu family of compilers.
|-
| --output=<path>
| rowspan="2"| Output file or directory. The default is the current directory.
|-
| -o<path>
|-
| --targ_big_endian
| Target uses a big endian by representation. The default is little endian.
|-
| --targ_plain_char_is_unsigned
| Target uses unsigned chars to represent “plain” char. The default is signed.
|-
| --targ_adaptive_enum
| Target has adaptive enums. The default is no adaptive enums.
|-
| --targ_pack_alignment=<align>
| Target struct pack alignment. The default is 16. Possible values are 1, 2, 4, 8 or 16.
|-
| --targ_sizeof_char=<size>
| Target platform size of char. Default is 1. Possible values are 1, 2, 4, 8, or 16.
|-
| --targ_alignof_char=<align>
| Target platform alignment of char. Default is 1. Possible values are 1, 2, 4, 8 or 16.
|-
| --targ_sizeof_short=<size>
| Default is 2.
|-
| --targ_alignof_short=<align>
| Default is 2.
|-
| --targ_sizeof_int=<size>
| Default is 4.
|-
| --targ_alignof_int=<align>
| Default is 4.
|-
| --targ_sizeof_long=<size>
| Default is 4.
|-
| --targ_alignof_long=<align>
| Default is 4.
|-
| --targ_sizeof_long_long=<size>
| Default is 8.
|-
| --targ_alignof_long_long=<align>
| Default is 8.
|-
| --targ_sizeof_float=<size>
| Default is 4.
|-
| --targ_alignof_float=<align>
| Default is 4
|-
| --targ_sizeof_double=<size>
| Default is 8.
|-
| --targ_alignof_double=<align>
| Default is 8.
|-
| --targ_sizeof_long_double=<size>
| Default is 8
|-
| --targ_alignof_long_double=<align>
| Default is 8.
|-
| --options_file=<file>
| A file that contains commandline options.  This option is necessary if the length of the commandline string exceeds system limits. Otherwise it is provided only as a convenience.
|}


=== The '''s2sbind''' Component ===
    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


==== Syntax and Options ====
    s2sinstrument –-im_name=test –-implement -–mode=S(f10,f11) -–mode=P(f20,f21) test.sidb


=== The '''s2sinstrument''' Component ===
==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:


==== Syntax and Options ====
    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

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:

  1. The STRIDE Compiler (s2scompile)
  2. The STRIDE Database Binder (s2sbind)
  3. 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