Intercept Module - Revision history

Marku at 15:54, 4 July 2015

2015-07-04T15:54:04Z

← Older revision		Revision as of 15:54, 4 July 2015
Line 1:		Line 1:
	~~== About Intercept Modules<br> ==~~		__NOTOC__
			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 (see the [[Build Tools\|Build Tools]] page). The Intercept Module, or IM, is created based on selected interfaces or test units that have been "captured", or identified through a subset of STRIDE 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.<br>
	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 (see the [[Build Tools\|Build Tools]] page). 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 ~~(see [[scl_function]])~~ 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.~~<br>~~

	<br>

	The [[s2sinstrument]] executable generates the code for an intercept module for selected functions or test units. Generation can be tailored to include different instrumentation details for each function.		The [[s2sinstrument]] executable generates the code for an intercept module for selected functions or test units. Generation can be tailored to include different instrumentation details for each function.
Line 12:		Line 9:
	*The Name Mangling header file (''imname'''''IM.h''')<br>This file must be included in all of your C files that are using ''Interceptors'' (formal ''Delegates'') - ''Remote'' (aka ''Dynamic'') or ''Trace''. 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 <tt>#include</tt>'d in the source. ''Stub'' and ''Proxy'' functions do not require this file		*The Name Mangling header file (''imname'''''IM.h''')<br>This file must be included in all of your C files that are using ''Interceptors'' (formal ''Delegates'') - ''Remote'' (aka ''Dynamic'') or ''Trace''. 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 <tt>#include</tt>'d in the source. ''Stub'' and ''Proxy'' functions do not require this file
	*The IM Entry point header file (''imname'''''IMEntry.h''')<br>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.		*The IM Entry point header file (''imname'''''IMEntry.h''')<br>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.

	~~<br>~~

	The following examples describe integration and testing situations that would require generation of one or more intercept modules:		The following examples describe integration and testing situations that would require generation of one or more intercept modules:
Line 21:		Line 16:
	*To trace on a function that completely resides on the target (e.g., both the called and the calling functions are co-located on the target platform), you must generate an intercept module containing a '''trace interceptor''' (formal '''trace delegate''') and include it in the target build.		*To trace on a function that completely resides on the target (e.g., both the called and the calling functions are co-located on the target platform), you must generate an intercept module containing a '''trace interceptor''' (formal '''trace delegate''') and include it in the target build.
	*To be able to dynamically "move" a function back and forth between host and target platforms during integration and testing without rebuilding the target application, you must generate an intercept module containing a '''remote interceptor''' (formal '''dynamic delegate''') and include it in the target build.<br>		*To be able to dynamically "move" a function back and forth between host and target platforms during integration and testing without rebuilding the target application, you must generate an intercept module containing a '''remote interceptor''' (formal '''dynamic delegate''') and include it in the target build.<br>

	~~<br>~~

	~~== Stubs, Proxies, and Interceptors ==~~

	Target instrumentation is handled via stubs, proxies, and interceptors, each of which provide distinct functionality.<br>		Target instrumentation is handled via stubs, proxies, and interceptors, each of which provide distinct functionality.<br>

	~~<br>~~		[[Image:PROXYSTUB.gif\|center]]

	~~[[Image:PROXYSTUB.gif\|center]]~~

	=== Stub ===		= Stub =

	A stub is required in order to call a function, f(), on the target from the host.		A stub is required in order to call a function, f(), on the target from the host.
Line 43:		Line 33:
	When a proxy and a stub exist for a given function, the stub is never on the same platform as the proxy.		When a proxy and a stub exist for a given function, the stub is never on the same platform as the proxy.

	=== Proxy ===		= Proxy =

	A proxy is required in order to transparently intercept a target call to a function, f(), and remote the call to a host implementation of f().		A proxy is required in order to transparently intercept a target call to a function, f(), and remote the call to a host implementation of f().
Line 56:		Line 46:
	<br> '''Note:''' A stub and a proxy cannot simultaneously coexist for the same function. Only one can be used for any given test configuration.		<br> '''Note:''' A stub and a proxy cannot simultaneously coexist for the same function. Only one can be used for any given test configuration.

	=== Interceptor ===		= Interceptor =

	An interceptor ~~(formally known as delegate)~~ is a specialized type of proxy. It can perform the following tasks:		An interceptor is a specialized type of proxy. It can perform the following tasks:

	*Transparently trace all calls to a method, f(), whose implementation resides on the target. All calls and parameter data can be captured and recorded. This type of interceptor is called a '''Trace Interceptor''' (formally known as '''Trace Delegate''').		*Transparently trace all calls to a method, f(), whose implementation resides on the target. All calls and parameter data can be captured and recorded. This type of interceptor is called a '''Trace Interceptor''' (formally known as '''Trace Delegate''').
Line 68:		Line 58:
	A Remote Interceptor inserts itself between the caller and the callee in the same way as a Trace Interceptor, but its logic is different. It checks certain state information to determine whether to route the call to a host implementation (and override the owner) of f(), or to allow the call to proceed to the local implementation (owner) of f().		A Remote Interceptor inserts itself between the caller and the callee in the same way as a Trace Interceptor, but its logic is different. It checks certain state information to determine whether to route the call to a host implementation (and override the owner) of f(), or to allow the call to proceed to the local implementation (owner) of f().

	==== Interceptor Options ====		== Interceptor Options ==

	===== ''Definition/Reference'' =====		=== ''Definition/Reference'' ===

	To insert an interceptor between a ''reference'' ~~(''calling'' aka ''user'')~~ function and ''definition'' ~~(''called'' aka ''owner'')~~ function, you must choose how function ~~[[Name Mangling\|~~name mangling]] will be handled. Name mangling describes the automatic source transformation required for an interceptor to insert itself between caller and callee. There are two options for handling name mangling, one of which must be chosen:		To insert an interceptor between a ''reference'' function and ''definition'' function, you must choose how function ''name mangling'' will be handled. Name mangling describes the automatic source transformation required for an interceptor to insert itself between caller and callee. There are two options for handling name mangling, one of which must be chosen:

	*A call to a function f() is transformed to "__im_f()” to allow interception of the call. This is referred to as '''reference mangling'''.		*A call to a function f() is transformed to "__im_f()” to allow interception of the call. This is referred to as '''reference mangling'''.
Line 78:		Line 68:
	*The implemention of f() can be transformed to "__im_f()”. This is referred to as '''definition mangling'''.		*The implemention of f() can be transformed to "__im_f()”. This is referred to as '''definition mangling'''.

	See the [[~~Name Mangling\|Understanding~~ Name Mangling]] page for a detailed explanation of name mangling and how it is used.		See the [[Name Mangling]] page for a detailed explanation of name mangling and how it is used.

	===== ''Implicit/Explicit'' =====		=== ''Implicit/Explicit'' ===

	An interceptor may have either implicit or explicit name mangling incorporated into it. By default, implicit mangling is used; this means that selected routines will be mangled using a ~~[[#~~Group_ID~~\|Group ID]]~~. If explicit mangling is used, you must explicitly mangle selected routines using the explicit macro "'''srTEST_INTERCEPT('''''<function_name>''''')'''". For detailed information about implicit and explicit name mangling, including examples, ~~click~~ [[Name Mangling~~\|here~~]].		An interceptor may have either implicit or explicit name mangling incorporated into it. By default, implicit mangling is used; this means that selected routines will be mangled using a '''Group_ID'''. If explicit mangling is used, you must explicitly mangle selected routines using the explicit macro "'''srTEST_INTERCEPT('''''<function_name>''''')'''". For detailed information about implicit and explicit name mangling, including examples, see the [[Name Mangling]] page.

	===== ''Group ID'' =====		=== ''Group ID'' ===

	A Group ID assigns a special symbolic constant, declared in the Intercept Module name mangling header file (xxxIM.h), that can be used by the preprocessor to mangle a subset of routines. A Group ID can be defined within the source file or defined as a compiler input parameter (preprocessor directive). Name mangling conflicts can be resolved using the Group ID(s).		A Group ID assigns a special symbolic constant, declared in the Intercept Module name mangling header file (xxxIM.h), that can be used by the preprocessor to mangle a subset of routines. A Group ID can be defined within the source file or defined as a compiler input parameter (preprocessor directive). Name mangling conflicts can be resolved using the Group ID(s).

	~~=== See also ===~~

	*[[Name Mangling\|Understanding Name Mangling]]
	*[[Build Integration]] for directions on how to generate an IM and add it to your target build
	*[[s2sinstrument\|Using s2sinstrument to generate an Intercept Module]]

	~~[[Category:Reference]]~~

Marku: /* Group ID */

2011-07-06T21:39:43Z

Group ID

← Older revision		Revision as of 21:39, 6 July 2011
Line 86:		Line 86:
	===== ''Group ID'' =====		===== ''Group ID'' =====

	A Group ID assigns a special symbolic constant, declared in the Intercept Module name mangling header file (xxxIM.h), that can be used by the preprocessor to mangle a subset of routines~~; successful use of Group ID(s) assumes that each source file (e.g., FuncA.c and FuncB.c) has its own header file (e.g., FuncA.h and FuncB.h)~~. A Group ID can be defined within the source file or defined as a compiler input parameter (preprocessor directive). Name mangling conflicts can be resolved using the Group ID(s).		A Group ID assigns a special symbolic constant, declared in the Intercept Module name mangling header file (xxxIM.h), that can be used by the preprocessor to mangle a subset of routines. A Group ID can be defined within the source file or defined as a compiler input parameter (preprocessor directive). Name mangling conflicts can be resolved using the Group ID(s).

	=== See also ===		=== See also ===

Ivailop: /* Interceptor */

2011-07-06T19:56:46Z

Interceptor

← Older revision		Revision as of 19:56, 6 July 2011
Line 70:		Line 70:
	==== Interceptor Options ====		==== Interceptor Options ====

	==== ''Definition/Reference'' ====		===== ''Definition/Reference'' =====

	To insert an interceptor between a ''reference'' (''calling'' aka ''user'') function and ''definition'' (''called'' aka ''owner'') function, you must choose how function [[Name Mangling\|name mangling]] will be handled. Name mangling describes the automatic source transformation required for an interceptor to insert itself between caller and callee. There are two options for handling name mangling, one of which must be chosen:~~<br>~~		To insert an interceptor between a ''reference'' (''calling'' aka ''user'') function and ''definition'' (''called'' aka ''owner'') function, you must choose how function [[Name Mangling\|name mangling]] will be handled. Name mangling describes the automatic source transformation required for an interceptor to insert itself between caller and callee. There are two options for handling name mangling, one of which must be chosen:

	#A call to a function f() is transformed to "__im_f()” to allow interception of the call. This is referred to as '''reference mangling'''.		*A call to a function f() is transformed to "__im_f()” to allow interception of the call. This is referred to as '''reference mangling'''.

	#The implemention of f() can be transformed to "__im_f()”. This is referred to as '''definition mangling'''.		*The implemention of f() can be transformed to "__im_f()”. This is referred to as '''definition mangling'''.

	See the [[Name Mangling\|Understanding Name Mangling]] page for a detailed explanation of name mangling and how it is used.		See the [[Name Mangling\|Understanding Name Mangling]] page for a detailed explanation of name mangling and how it is used.

	==== ''Implicit/Explicit'' ====		===== ''Implicit/Explicit'' =====

	An interceptor may have either implicit or explicit name mangling incorporated into it. By default, implicit mangling is used; this means that selected routines will be mangled using a [[#Group_ID\|Group ID]]. If explicit mangling is used, you must explicitly mangle selected routines using the explicit macro "'''srTEST_INTERCEPT('''''<function_name>''''')'''". For detailed information about implicit and explicit name mangling, including examples, click [[Name Mangling\|here]].		An interceptor may have either implicit or explicit name mangling incorporated into it. By default, implicit mangling is used; this means that selected routines will be mangled using a [[#Group_ID\|Group ID]]. If explicit mangling is used, you must explicitly mangle selected routines using the explicit macro "'''srTEST_INTERCEPT('''''<function_name>''''')'''". For detailed information about implicit and explicit name mangling, including examples, click [[Name Mangling\|here]].

	==== ''Group ID''~~<br>~~ ====		===== ''Group ID'' =====

	A Group ID assigns a special symbolic constant, declared in the Intercept Module name mangling header file (xxxIM.h), that can be used by the preprocessor to mangle a subset of routines; successful use of Group ID(s) assumes that each source file (e.g., FuncA.c and FuncB.c) has its own header file (e.g., FuncA.h and FuncB.h). A Group ID can be defined within the source file or defined as a compiler input parameter (preprocessor directive). Name mangling conflicts can be resolved using the Group ID(s).~~<br>~~		A Group ID assigns a special symbolic constant, declared in the Intercept Module name mangling header file (xxxIM.h), that can be used by the preprocessor to mangle a subset of routines; successful use of Group ID(s) assumes that each source file (e.g., FuncA.c and FuncB.c) has its own header file (e.g., FuncA.h and FuncB.h). A Group ID can be defined within the source file or defined as a compiler input parameter (preprocessor directive). Name mangling conflicts can be resolved using the Group ID(s).

	=== See also ===		=== See also ===

Ivailop: /* Definition/Reference */

2011-07-06T19:42:01Z

Definition/Reference

← Older revision		Revision as of 19:42, 6 July 2011
Line 74:		Line 74:
	To insert an interceptor between a ''reference'' (''calling'' aka ''user'') function and ''definition'' (''called'' aka ''owner'') function, you must choose how function [[Name Mangling\|name mangling]] will be handled. Name mangling describes the automatic source transformation required for an interceptor to insert itself between caller and callee. There are two options for handling name mangling, one of which must be chosen:<br>		To insert an interceptor between a ''reference'' (''calling'' aka ''user'') function and ''definition'' (''called'' aka ''owner'') function, you must choose how function [[Name Mangling\|name mangling]] will be handled. Name mangling describes the automatic source transformation required for an interceptor to insert itself between caller and callee. There are two options for handling name mangling, one of which must be chosen:<br>

	#A call to a function f() is transformed to "~~__imf~~()” to allow interception of the call. This is referred to as '''reference mangling'''.		#A call to a function f() is transformed to "__im_f()” to allow interception of the call. This is referred to as '''reference mangling'''.

	#The implemention of f() can be transformed to "~~__imf~~()”. This is referred to as '''definition mangling'''.~~<br>~~		#The implemention of f() can be transformed to "__im_f()”. This is referred to as '''definition mangling'''.

	See the [[Name Mangling\|Understanding Name Mangling]] page for a detailed explanation of name mangling and how it is used.		See the [[Name Mangling\|Understanding Name Mangling]] page for a detailed explanation of name mangling and how it is used.

Marku: /* About Intercept Modules */

2010-06-07T16:24:04Z

About Intercept Modules

← Older revision		Revision as of 16:24, 7 June 2010
Line 5:		Line 5:
	<br>		<br>

	The [[s2sinstrument]] executable~~, or alternatively, the Intercept Module Wizard in [[STRIDE Studio]] generate~~ the code for an intercept module for selected functions or test units. Generation can be tailored to include different instrumentation details for each function.		The [[s2sinstrument]] executable generates the code for an intercept module for selected functions or test units. Generation can be tailored to include different instrumentation details for each function.

	<br> Three files are created, each prepended with the name of the Intercept Module that you gave it when it was created:		<br> Three files are created, each prepended with the name of the Intercept Module that you gave it when it was created:

Ivailop: /* See also */

2010-05-07T20:11:56Z

Ivailop: /* See also */

2010-05-07T20:11:40Z

Ivailop: /* Implicit/Explicit */

2009-12-23T22:46:07Z

Implicit/Explicit

← Older revision		Revision as of 22:46, 23 December 2009
Line 82:		Line 82:
	==== ''Implicit/Explicit'' ====		==== ''Implicit/Explicit'' ====

	An interceptor may have either implicit or explicit name mangling incorporated into it. By default, implicit mangling is used; this means that selected routines will be mangled using a [[#Group_ID\|Group ID]]. If explicit mangling is used, you must explicitly mangle selected routines using the explicit macro "'''~~imINTERCEPT~~('''''<function_name>''''')'''". For detailed information about implicit and explicit name mangling, including examples, click [[Name Mangling\|here]].		An interceptor may have either implicit or explicit name mangling incorporated into it. By default, implicit mangling is used; this means that selected routines will be mangled using a [[#Group_ID\|Group ID]]. If explicit mangling is used, you must explicitly mangle selected routines using the explicit macro "'''srTEST_INTERCEPT('''''<function_name>''''')'''". For detailed information about implicit and explicit name mangling, including examples, click [[Name Mangling\|here]].

	==== ''Group ID''<br> ====		==== ''Group ID''<br> ====

Ivailop: /* Stubs, Proxies, and Delegates
*/

2009-03-24T19:44:44Z

Stubs, Proxies, and Delegates<br>

← Older revision		Revision as of 19:44, 24 March 2009
Line 24:		Line 24:
	<br>		<br>

	== Stubs, Proxies, and ~~Delegates<br>~~ ==		== Stubs, Proxies, and Interceptors ==

	Target instrumentation is handled via stubs, proxies, and ~~delegates~~, each of which provide distinct functionality.<br>		Target instrumentation is handled via stubs, proxies, and interceptors, each of which provide distinct functionality.<br>

	<br>		<br>
Line 32:		Line 32:
	[[Image:PROXYSTUB.gif\|center]]		[[Image:PROXYSTUB.gif\|center]]

	~~<br>~~		=== Stub ===

	=== Stub~~<br>~~ ===

	A stub is required in order to call a function, f(), on the target from the host.		A stub is required in order to call a function, f(), on the target from the host.
Line 45:		Line 43:
	When a proxy and a stub exist for a given function, the stub is never on the same platform as the proxy.		When a proxy and a stub exist for a given function, the stub is never on the same platform as the proxy.

	~~<br>~~		=== Proxy ===

	=== Proxy~~<br>~~ ===

	A proxy is required in order to transparently intercept a target call to a function, f(), and remote the call to a host implementation of f().		A proxy is required in order to transparently intercept a target call to a function, f(), and remote the call to a host implementation of f().
Line 60:		Line 56:
	<br> '''Note:''' A stub and a proxy cannot simultaneously coexist for the same function. Only one can be used for any given test configuration.		<br> '''Note:''' A stub and a proxy cannot simultaneously coexist for the same function. Only one can be used for any given test configuration.

	~~<br>~~		=== Interceptor ===

	~~=== Delegate<br> ===~~		An interceptor (formally known as delegate) is a specialized type of proxy. It can perform the following tasks:

	~~A delegate is~~ a ~~specialized~~ type of ~~proxy~~. ~~A delegate can perform the following tasks:~~		*Transparently trace all calls to a method, f(), whose implementation resides on the target. All calls and parameter data can be captured and recorded. This type of interceptor is called a '''Trace Interceptor''' (formally known as '''Trace Delegate''').

	*Transparently trace all calls to a method, f(), whose implementation resides on the target. All calls and parameter data can be captured and recorded. This type of delegate is called a '''Tracing Delegate'''.		*Transparently route calls to either a target- or host-based implementation of f(). This routing is dynamic and controlled by the host. This type of interceptor is called a '''Remote Interceptor''' (formally known as '''Dynamic Delegate''').
	*Transparently route calls to either a target- or host-based implementation of f(). This routing is dynamic and controlled by the host. This type of ~~delegate~~ is called a '''Dynamic Delegate'''.

	A ~~Tracing Delegate~~ intercepts calls to f() and records tracing information such as time, input parameters, etc. before passing control to the local implementation of f(). Upon the return from f(), the ~~delegate~~ again records tracing information before passing control back to the caller~~. The delegate inserts itself between the caller and the callee in order to capture tracing information~~.		A Trace Interceptor intercepts calls to f(), by inserts itself between the caller and the callee, and records tracing information such as time, input parameters, etc. before passing control to the local implementation of f(). Upon the return from f(), the interceptor again records tracing information before passing control back to the caller.

	A ~~Dynamic Delegate~~ inserts itself between the caller and the callee in the same way as a ~~Tracing Delegate~~, but its logic is different. ~~In addition to recording tracing information, it contains logic to check~~ certain state information to determine whether to route the call to a host implementation (and override the owner) of f(), or to allow the call to proceed to the local implementation (owner) of f().		A Remote Interceptor inserts itself between the caller and the callee in the same way as a Trace Interceptor, but its logic is different. It checks certain state information to determine whether to route the call to a host implementation (and override the owner) of f(), or to allow the call to proceed to the local implementation (owner) of f().

	~~'''Note:''' A Dynamic Delegate is always a Tracing Delegate, but depending upon instructions you give the Intercept Module Wizard, a Tracing Delegate may or may not be a Dynamic Delegate.<br><br>~~		==== Interceptor Options ====

	==== ~~Delegate Options<br>~~ ====		==== ''Definition/Reference'' ====

	~~====~~ ''~~Owner/User~~''<br> ~~====~~		To insert an interceptor between a ''reference'' (''calling'' aka ''user'') function and ''definition'' (''called'' aka ''owner'') function, you must choose how function [[Name Mangling\|name mangling]] will be handled. Name mangling describes the automatic source transformation required for an interceptor to insert itself between caller and callee. There are two options for handling name mangling, one of which must be chosen:<br>

	~~To insert~~ a ~~delegate between a user~~ (~~calling~~) ~~function and owner~~ (~~called~~) ~~function, you must choose how function [[Name Mangling\|name mangling]] will be handled~~. ~~Name~~ mangling ~~describes the automatic source transformation required for a delegate to insert itself between caller and callee~~. ~~There are two options for handling name mangling, one of which must be chosen when using delegates:<br>~~		#A call to a function f() is transformed to "__imf()” to allow interception of the call. This is referred to as '''reference mangling'''.

	~~#A call to a function f() is transformed to "__imf()” to allow the delegate to intercept the call. This is referred to as '''user mangling'''.~~		#The implemention of f() can be transformed to "__imf()”. This is referred to as '''definition mangling'''.<br>
	#The implemention of f() can be transformed to "__imf()”. This is referred to as '''~~owner~~ mangling'''.<br>

	See the [[Name Mangling\|Understanding Name Mangling]] page for a detailed explanation of name mangling and how it is used.~~<br>~~		See the [[Name Mangling\|Understanding Name Mangling]] page for a detailed explanation of name mangling and how it is used.

	==== ''Implicit/Explicit''~~<br>~~ ====		==== ''Implicit/Explicit'' ====

	~~A delegate~~ may have either implicit or explicit mangling incorporated into it. By default, implicit mangling is used; this means that selected routines will be mangled using a [[#Group_ID\|Group ID]]. If explicit mangling is used, you must explicitly mangle selected routines using the explicit macro "'''~~imDELEGATE~~('''''<function_name>''''')'''". For detailed information about implicit and explicit mangling, including examples, click [[Name Mangling\|here]].		An interceptor may have either implicit or explicit name mangling incorporated into it. By default, implicit mangling is used; this means that selected routines will be mangled using a [[#Group_ID\|Group ID]]. If explicit mangling is used, you must explicitly mangle selected routines using the explicit macro "'''imINTERCEPT('''''<function_name>''''')'''". For detailed information about implicit and explicit name mangling, including examples, click [[Name Mangling\|here]].

	==== ''Group ID''<br> ====		==== ''Group ID''<br> ====

	A Group ID assigns a special symbolic constant, declared in the Intercept Module ~~delegate~~ mangling header file (xxxIM.h), that can be used by the preprocessor to mangle a subset of routines; successful use of Group ID(s) assumes that each source file (e.g., FuncA.c and FuncB.c) has its own header file (e.g., FuncA.h and FuncB.h). A Group ID can be defined within the source file or defined as a compiler input parameter. Name mangling conflicts can be resolved using the Group ID(s).<br>		A Group ID assigns a special symbolic constant, declared in the Intercept Module name mangling header file (xxxIM.h), that can be used by the preprocessor to mangle a subset of routines; successful use of Group ID(s) assumes that each source file (e.g., FuncA.c and FuncB.c) has its own header file (e.g., FuncA.h and FuncB.h). A Group ID can be defined within the source file or defined as a compiler input parameter (preprocessor directive). Name mangling conflicts can be resolved using the Group ID(s).<br>

	~~<br>'''~~See also~~'''~~		=== See also ===

	*[[Name Mangling\|Understanding Name Mangling]]		*[[Name Mangling\|Understanding Name Mangling]]

Ivailop: /* About Intercept Modules
*/

2009-03-24T19:28:57Z

About Intercept Modules<br>

← Older revision		Revision as of 19:28, 24 March 2009
Line 10:		Line 10:

	*The Intercept Module source file (''imname'''''IM.c''' or ''imname'''''IM.cpp''')<br>This file contains the code that allows the ''remoting'' of functions so that they can be accessed by the Target and Host.		*The Intercept Module source file (''imname'''''IM.c''' or ''imname'''''IM.cpp''')<br>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 (''imname'''''IM.h''')<br>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 <tt>#include</tt>'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 Name Mangling header file (''imname'''''IM.h''')<br>This file must be included in all of your C files that are using ''Interceptors'' (formal ''Delegates'') - ''Remote'' (aka ''Dynamic'') or ''Trace''. 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 <tt>#include</tt>'d in the source. ''Stub'' and ''Proxy'' functions do not require this file
	*The IM Entry point header file (''imname'''''IMEntry.h''')<br>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.		*The IM Entry point header file (''imname'''''IMEntry.h''')<br>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.

Line 19:		Line 19:
	*To call a function on the target platform from the host, you must generate an intercept module containing a '''stub''' and include it in the target build.		*To call a function on the target platform from the host, you must generate an intercept module containing a '''stub''' and include it in the target build.
	*To call a function on the host platform from a function on the target, you must generate an intercept module containing a '''proxy''' and include it in the target build.		*To call a function on the host platform from a function on the target, you must generate an intercept module containing a '''proxy''' and include it in the target build.
	*To trace on a function that completely resides on the target (e.g., both the called and the calling functions are co-located on the target platform), you must generate an intercept module containing a '''~~tracing~~ delegate''' and include it in the target build.		*To trace on a function that completely resides on the target (e.g., both the called and the calling functions are co-located on the target platform), you must generate an intercept module containing a '''trace interceptor''' (formal '''trace delegate''') and include it in the target build.
	*To be able to dynamically "move" a function back and forth between host and target platforms during integration and testing without rebuilding the target application, you must generate an intercept module containing a '''dynamic delegate''' and include it in the target build.<br>		*To be able to dynamically "move" a function back and forth between host and target platforms during integration and testing without rebuilding the target application, you must generate an intercept module containing a '''remote interceptor''' (formal '''dynamic delegate''') and include it in the target build.<br>

	<br>		<br>

← Older revision		Revision as of 20:11, 7 May 2010
Line 92:		Line 92:
	*[[Name Mangling\|Understanding Name Mangling]]		*[[Name Mangling\|Understanding Name Mangling]]
	*[[Build Integration]] for directions on how to generate an IM and add it to your target build		*[[Build Integration]] for directions on how to generate an IM and add it to your target build
	*[[Using s2sinstrument to generate an Intercept Module]]		*[[s2sinstrument\|Using s2sinstrument to generate an Intercept Module]]

	[[Category:Reference]]		[[Category:Reference]]

← Older revision		Revision as of 20:11, 7 May 2010
Line 91:		Line 91:

	*[[Name Mangling\|Understanding Name Mangling]]		*[[Name Mangling\|Understanding Name Mangling]]
	*~~'''~~[[~~Integrating the Intercept Module (IM)\|Integrating the Intercept Module (IM)~~]]~~'''~~ for directions on how to generate an IM and add it to your target build		*[[Build Integration]] for directions on how to generate an IM and add it to your target build
	*[[~~S2sinstrument\|~~Using s2sinstrument to generate an Intercept Module]]		*[[Using s2sinstrument to generate an Intercept Module]]

	[[Category:Reference]]		[[Category:Reference]]

Intercept Module - Revision history

Marku at 15:54, 4 July 2015

Marku: /* Group ID */

Ivailop: /* Interceptor */

Ivailop: /* Definition/Reference */

Marku: /* About Intercept Modules */

Ivailop: /* See also */

Ivailop: /* See also */

Ivailop: /* Implicit/Explicit */

Ivailop: /* Stubs, Proxies, and Delegates */

Ivailop: /* About Intercept Modules */

Ivailop: /* Stubs, Proxies, and Delegates
*/

Ivailop: /* About Intercept Modules
*/