Name Mangling - Revision history

Marku at 20:12, 6 July 2015

2015-07-06T20:12:15Z

← Older revision		Revision as of 20:12, 6 July 2015
Line 40:		Line 40:

	To enable Intercept Modules to be regenerated continuously and to allow the user the option to add and/or remove interceptors, an [[#Explicit_Mangling\|explicit macro]] is generated for each routine. If a routine is not selected as an interceptor, an explicit macro will be generated so that name mangling will not occur. Also, if use of the Intercept Module is turned off via the source file (e.g., <tt>#undef STRIDE_ENABLED</tt> or <tt>#define STRIDE_ENABLED 0</tt>), the macros will not perform name mangling. This allows users to leave explicit macros in their source code, even if the Intercept Module is not being used.		To enable Intercept Modules to be regenerated continuously and to allow the user the option to add and/or remove interceptors, an [[#Explicit_Mangling\|explicit macro]] is generated for each routine. If a routine is not selected as an interceptor, an explicit macro will be generated so that name mangling will not occur. Also, if use of the Intercept Module is turned off via the source file (e.g., <tt>#undef STRIDE_ENABLED</tt> or <tt>#define STRIDE_ENABLED 0</tt>), the macros will not perform name mangling. This allows users to leave explicit macros in their source code, even if the Intercept Module is not being used.

	~~== See also ==~~

	*[[Intercept Module\|Intercept Module Overview]]
	*[[S2sinstrument\|Using s2sinstrument.exe to generate an Intercept Module]]

	~~[[Category:Reference]]~~

Marku: /* What is Name Mangling? */

2011-07-06T21:26:55Z

What is Name Mangling?

← Older revision		Revision as of 21:26, 6 July 2011
Line 14:		Line 14:


	The name mangling ~~could also be~~ either '''~~implicit~~''' or '''~~explicit~~''' ~~name~~. By default, implicit mangling is used; this means that selected routines will be mangled using a ~~choosen~~ [[Intercept_Module#Group_ID\|Group ID]].		The name mangling is either done '''implicitly''' or '''explicitly''' during the compile process. By default, '''implicit''' mangling is used; this means that selected routines will be mangled by using a chosen [[Intercept_Module#Group_ID\|Group ID]] and including the Intercept Module header file. Where '''explicit''' mangling requires the additional step of adding a macro.

	== Name Mangling Conflicts ==		== Name Mangling Conflicts ==

Ivailop: /* Name Mangling Conflicts */

2011-07-06T19:54:25Z

Name Mangling Conflicts

← Older revision		Revision as of 19:54, 6 July 2011
Line 28:		Line 28:
	If the reference and the definition of the same routine, f(), exist in the same source file, the use of explicit mangling is required to resolve the mangling conflict. If the conflict is not resolved, the user will bypass the interceptor by using the mangled name when making the call to the routine.		If the reference and the definition of the same routine, f(), exist in the same source file, the use of explicit mangling is required to resolve the mangling conflict. If the conflict is not resolved, the user will bypass the interceptor by using the mangled name when making the call to the routine.

	===== ''Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor'' ====		==== ''Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor'' ====

	By default, interceptors are definition-focused. An referenced-focused interceptor is used to mangle the actual routine; thus, every caller of the routine goes through the interceptor. There are use cases when source code for the routines cannot be accessed (i.e., as with libraries). A referenced-focused interceptor can be used to mangle the caller instead of the routine to be called (callee). Reference-focused interceptors typically do not have mangling conflicts, except when multiple callers exist in the same source file, but only a subset is targeted to go through the interceptor. Explicit mangling is used to avoid this type of mangling conflict.		By default, interceptors are definition-focused. An referenced-focused interceptor is used to mangle the actual routine; thus, every caller of the routine goes through the interceptor. There are use cases when source code for the routines cannot be accessed (i.e., as with libraries). A referenced-focused interceptor can be used to mangle the caller instead of the routine to be called (callee). Reference-focused interceptors typically do not have mangling conflicts, except when multiple callers exist in the same source file, but only a subset is targeted to go through the interceptor. Explicit mangling is used to avoid this type of mangling conflict.
Line 35:		Line 35:
	<source lang="c">		<source lang="c">
	#include "MyHeader.h"		#include "MyHeader.h"
	#define <MyGroupID>		#define MyGroupID
	#include "xxxIM.h"		#include "xxxIM.h"
	</source>		</source>

Ivailop: /* What is Name Mangling? */

2011-07-06T19:51:52Z

What is Name Mangling?

← Older revision		Revision as of 19:51, 6 July 2011
Line 1:		Line 1:
	== What is Name Mangling? ==		== What is Name Mangling? ==

	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 when using interceptors:~~<br>~~		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 when using interceptors:

	#A call to a function f() is transformed to "__im_f()” to allow interception the call. This is referred to as '''reference mangling'''.		*A call to a function f() is transformed to "__im_f()” to allow interception 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'''.

	For example, to use a interceptor to trace all calls to a function, f():~~<br>~~		For example, to use a interceptor to trace all calls to a function, f():

	*If we use '''reference mangling''', all calls to f() are transformed to be calls to __im_f(). The interceptor is implemented as __im_f(). The original implementation of f() remains unchanged. This allows interception of all calls and takes the appropriate action.~~<br>~~		*If we use '''reference mangling''', all calls to f() are transformed to be calls to __im_f(). The interceptor is implemented as __im_f(). The original implementation of f() remains unchanged. This allows interception of all calls and takes the appropriate action.

	*If we use '''definition mangling''', the implementation of f() is changed from f(){...} to __im_f(){...}. The interceptor is implemented as f() in order to intercept all calls.		*If we use '''definition mangling''', the implementation of f() is changed from f(){...} to __im_f(){...}. The interceptor is implemented as f() in order to intercept all calls.


			The name mangling could also be either '''implicit''' or '''explicit''' name. By default, implicit mangling is used; this means that selected routines will be mangled using a choosen [[Intercept_Module#Group_ID\|Group ID]].

	== Name Mangling Conflicts ==		== Name Mangling Conflicts ==

Ivailop: /* Name Mangling Conflicts */

2011-07-06T19:47:26Z

Name Mangling Conflicts

← Older revision		Revision as of 19:47, 6 July 2011
Line 16:		Line 16:
	== Name Mangling Conflicts ==		== Name Mangling Conflicts ==

	A mangling conflict applies only to interceptors. It exists when the name of a routine requires mangling, but there also exists other references to the same name within the same source file. The other references will inadvertently be mangled by the preprocessor. ~~<br><br>~~		A mangling conflict applies only to interceptors. It exists when the name of a routine requires mangling, but there also exists other references to the same name within the same source file. The other references will inadvertently be mangled by the preprocessor.

	<span id="Explicit_Mangling">'''Explicit mangling'''</span> is used to resolve these type of name mangling conflicts. Explicit mangling uses the explicit macro "'''srTEST_INTERCEPT('''<function_name>''')'''", which explicitly mangles the name of "f()" to "__im_f()". The explicit macro is defined in the Intercept Module name mangling header file (xxxIM.h). Explicit mangling requires [[Intercept Module#Group ID\|Group ID(s)]] to be defined (#define MyGroupID) in the source file of the caller/callee of the routine to protect against the inclusion of unnecessary defined types.		<span id="Explicit_Mangling">'''Explicit mangling'''</span> is used to resolve these type of name mangling conflicts. Explicit mangling uses the explicit macro "'''srTEST_INTERCEPT('''<function_name>''')'''", which explicitly mangles the name of "f()" to "__im_f()". The explicit macro is defined in the Intercept Module name mangling header file (xxxIM.h). Explicit mangling requires [[Intercept Module#Group ID\|Group ID(s)]] to be defined (#define MyGroupID) in the source file of the caller/callee of the routine to protect against the inclusion of unnecessary defined types.
Line 22:		Line 22:
	The following examples demonstrate situations where explicit mangling can be used to resolve mangling conflicts:		The following examples demonstrate situations where explicit mangling can be used to resolve mangling conflicts:

	~~#The definition and the reference of the same routine, f(), exist in the same source file.~~		==== ''The reference and the definition of the same routine, f(), exist in the same source file'' ====

	~~#Two users of a routine, f(), exist in the same source file, but only one is a intercepted at [[Intercept Module#Definition/Reference\|reference]].~~

	=== The reference and the definition of the same routine, f(), exist in the same source file ===

	If the reference and the definition of the same routine, f(), exist in the same source file, the use of explicit mangling is required to resolve the mangling conflict. If the conflict is not resolved, the user will bypass the interceptor by using the mangled name when making the call to the routine.		If the reference and the definition of the same routine, f(), exist in the same source file, the use of explicit mangling is required to resolve the mangling conflict. If the conflict is not resolved, the user will bypass the interceptor by using the mangled name when making the call to the routine.

	=== Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor ===		===== ''Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor'' ====

	By default, interceptors are definition-focused. An referenced-focused interceptor is used to mangle the actual routine; thus, every caller of the routine goes through the interceptor. There are use cases when source code for the routines cannot be accessed (i.e., as with libraries). A referenced-focused interceptor can be used to mangle the caller instead of the routine to be called (callee). Reference-focused interceptors typically do not have mangling conflicts, except when multiple callers exist in the same source file, but only a subset is targeted to go through the interceptor. Explicit mangling is used to avoid this type of mangling conflict.		By default, interceptors are definition-focused. An referenced-focused interceptor is used to mangle the actual routine; thus, every caller of the routine goes through the interceptor. There are use cases when source code for the routines cannot be accessed (i.e., as with libraries). A referenced-focused interceptor can be used to mangle the caller instead of the routine to be called (callee). Reference-focused interceptors typically do not have mangling conflicts, except when multiple callers exist in the same source file, but only a subset is targeted to go through the interceptor. Explicit mangling is used to avoid this type of mangling conflict.

Ivailop: /* Name Mangling Conflicts */

2011-07-06T19:43:38Z

Name Mangling Conflicts

← Older revision		Revision as of 19:43, 6 July 2011
Line 26:		Line 26:
	#Two users of a routine, f(), exist in the same source file, but only one is a intercepted at [[Intercept Module#Definition/Reference\|reference]].		#Two users of a routine, f(), exist in the same source file, but only one is a intercepted at [[Intercept Module#Definition/Reference\|reference]].

	=== ~~''Mangling Conflict Example 1:~~ The reference and the definition of the same routine, f(), exist in the same source file'' ===		=== The reference and the definition of the same routine, f(), exist in the same source file ===

	If the reference and the definition of the same routine, f(), exist in the same source file, the use of explicit mangling is required to resolve the mangling conflict. If the conflict is not resolved, the user will bypass the interceptor by using the mangled name when making the call to the routine.		If the reference and the definition of the same routine, f(), exist in the same source file, the use of explicit mangling is required to resolve the mangling conflict. If the conflict is not resolved, the user will bypass the interceptor by using the mangled name when making the call to the routine.

	=== ~~''Mangling Conflict Example 2:~~ Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor'' ===		=== Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor ===

	By default, interceptors are definition-focused. An referenced-focused interceptor is used to mangle the actual routine; thus, every caller of the routine goes through the interceptor. There are use cases when source code for the routines cannot be accessed (i.e., as with libraries). A referenced-focused interceptor can be used to mangle the caller instead of the routine to be called (callee). Reference-focused interceptors typically do not have mangling conflicts, except when multiple callers exist in the same source file, but only a subset is targeted to go through the interceptor. Explicit mangling is used to avoid this type of mangling conflict.		By default, interceptors are definition-focused. An referenced-focused interceptor is used to mangle the actual routine; thus, every caller of the routine goes through the interceptor. There are use cases when source code for the routines cannot be accessed (i.e., as with libraries). A referenced-focused interceptor can be used to mangle the caller instead of the routine to be called (callee). Reference-focused interceptors typically do not have mangling conflicts, except when multiple callers exist in the same source file, but only a subset is targeted to go through the interceptor. Explicit mangling is used to avoid this type of mangling conflict.

Ivailop at 19:38, 6 July 2011

2011-07-06T19:38:43Z

← Older revision		Revision as of 19:38, 6 July 2011
Line 1:		Line 1:
	~~== Intercept Module Terminology: Understanding Name Mangling ==~~		== What is Name Mangling? ==

	=== What is Name Mangling? ===

	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 when using interceptors:<br>		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 when using interceptors:<br>
Line 16:		Line 14:


	==== Name Mangling Conflicts ====		== Name Mangling Conflicts ==

	A mangling conflict applies only to interceptors. It exists when the name of a routine requires mangling, but there also exists other references to the same name within the same source file. The other references will inadvertently be mangled by the preprocessor. <br><br>		A mangling conflict applies only to interceptors. It exists when the name of a routine requires mangling, but there also exists other references to the same name within the same source file. The other references will inadvertently be mangled by the preprocessor. <br><br>
Line 28:		Line 26:
	#Two users of a routine, f(), exist in the same source file, but only one is a intercepted at [[Intercept Module#Definition/Reference\|reference]].		#Two users of a routine, f(), exist in the same source file, but only one is a intercepted at [[Intercept Module#Definition/Reference\|reference]].

	==== ''Mangling Conflict Example 1: The reference and the definition of the same routine, f(), exist in the same source file'' ====		=== ''Mangling Conflict Example 1: The reference and the definition of the same routine, f(), exist in the same source file'' ===

	If the reference and the definition of the same routine, f(), exist in the same source file, the use of explicit mangling is required to resolve the mangling conflict. If the conflict is not resolved, the user will bypass the interceptor by using the mangled name when making the call to the routine.		If the reference and the definition of the same routine, f(), exist in the same source file, the use of explicit mangling is required to resolve the mangling conflict. If the conflict is not resolved, the user will bypass the interceptor by using the mangled name when making the call to the routine.

	~~<br>~~		=== ''Mangling Conflict Example 2: Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor'' ===

	==== ''Mangling Conflict Example 2: Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor'' ====

	By default, interceptors are definition-focused. An referenced-focused interceptor is used to mangle the actual routine; thus, every caller of the routine goes through the interceptor. There are use cases when source code for the routines cannot be accessed (i.e., as with libraries). A referenced-focused interceptor can be used to mangle the caller instead of the routine to be called (callee). Reference-focused interceptors typically do not have mangling conflicts, except when multiple callers exist in the same source file, but only a subset is targeted to go through the interceptor. Explicit mangling is used to avoid this type of mangling conflict.		By default, interceptors are definition-focused. An referenced-focused interceptor is used to mangle the actual routine; thus, every caller of the routine goes through the interceptor. There are use cases when source code for the routines cannot be accessed (i.e., as with libraries). A referenced-focused interceptor can be used to mangle the caller instead of the routine to be called (callee). Reference-focused interceptors typically do not have mangling conflicts, except when multiple callers exist in the same source file, but only a subset is targeted to go through the interceptor. Explicit mangling is used to avoid this type of mangling conflict.
Line 47:		Line 43:
	To enable Intercept Modules to be regenerated continuously and to allow the user the option to add and/or remove interceptors, an [[#Explicit_Mangling\|explicit macro]] is generated for each routine. If a routine is not selected as an interceptor, an explicit macro will be generated so that name mangling will not occur. Also, if use of the Intercept Module is turned off via the source file (e.g., <tt>#undef STRIDE_ENABLED</tt> or <tt>#define STRIDE_ENABLED 0</tt>), the macros will not perform name mangling. This allows users to leave explicit macros in their source code, even if the Intercept Module is not being used.		To enable Intercept Modules to be regenerated continuously and to allow the user the option to add and/or remove interceptors, an [[#Explicit_Mangling\|explicit macro]] is generated for each routine. If a routine is not selected as an interceptor, an explicit macro will be generated so that name mangling will not occur. Also, if use of the Intercept Module is turned off via the source file (e.g., <tt>#undef STRIDE_ENABLED</tt> or <tt>#define STRIDE_ENABLED 0</tt>), the macros will not perform name mangling. This allows users to leave explicit macros in their source code, even if the Intercept Module is not being used.

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

	*[[Intercept Module\|Intercept Module Overview]]		*[[Intercept Module\|Intercept Module Overview]]

Ivailop at 19:35, 6 July 2011

2011-07-06T19:35:17Z

← Older revision		Revision as of 19:35, 6 July 2011
Line 1:		Line 1:
	= Intercept Module Terminology: Understanding Name Mangling~~<br>~~ =		== Intercept Module Terminology: Understanding Name Mangling ==

	=== What is Name Mangling? ===		=== What is Name Mangling? ===
Line 26:		Line 26:
	#The definition and the reference of the same routine, f(), exist in the same source file.		#The definition and the reference of the same routine, f(), exist in the same source file.

	#Two users of a routine, f(), exist in the same source file, but only one is a intercepted at [[Intercept Module#Definition/Reference\|reference]].~~<br>~~		#Two users of a routine, f(), exist in the same source file, but only one is a intercepted at [[Intercept Module#Definition/Reference\|reference]].

	==== ''Mangling Conflict Example 1: The reference and the definition of the same routine, f(), exist in the same source file'' ====		==== ''Mangling Conflict Example 1: The reference and the definition of the same routine, f(), exist in the same source file'' ====
Line 44:		Line 44:
	#include "xxxIM.h"		#include "xxxIM.h"
	</source>		</source>
	~~<br>~~

	To enable Intercept Modules to be regenerated continuously and to allow the user the option to add and/or remove interceptors, an [[#Explicit_Mangling\|explicit macro]] is generated for each routine. If a routine is not selected as an interceptor, an explicit macro will be generated so that name mangling will not occur. Also, if use of the Intercept Module is turned off via the source file (e.g., <tt>#undef STRIDE_ENABLED</tt> or <tt>#define STRIDE_ENABLED 0</tt>), the macros will not perform name mangling. This allows users to leave explicit macros in their source code, even if the Intercept Module is not being used.		To enable Intercept Modules to be regenerated continuously and to allow the user the option to add and/or remove interceptors, an [[#Explicit_Mangling\|explicit macro]] is generated for each routine. If a routine is not selected as an interceptor, an explicit macro will be generated so that name mangling will not occur. Also, if use of the Intercept Module is turned off via the source file (e.g., <tt>#undef STRIDE_ENABLED</tt> or <tt>#define STRIDE_ENABLED 0</tt>), the macros will not perform name mangling. This allows users to leave explicit macros in their source code, even if the Intercept Module is not being used.

Ivailop: /* Name Mangling Conflicts */

2009-12-23T22:46:47Z

Name Mangling Conflicts

← Older revision		Revision as of 22:46, 23 December 2009
Line 20:		Line 20:
	A mangling conflict applies only to interceptors. It exists when the name of a routine requires mangling, but there also exists other references to the same name within the same source file. The other references will inadvertently be mangled by the preprocessor. <br><br>		A mangling conflict applies only to interceptors. It exists when the name of a routine requires mangling, but there also exists other references to the same name within the same source file. The other references will inadvertently be mangled by the preprocessor. <br><br>

	<span id="Explicit_Mangling">'''Explicit mangling'''</span> is used to resolve these type of name mangling conflicts. Explicit mangling uses the explicit macro "'''~~imINTERCEPT~~('''<function_name>''')'''", which explicitly mangles the name of "f()" to "__im_f()". The explicit macro is defined in the Intercept Module name mangling header file (xxxIM.h). Explicit mangling requires [[Intercept Module#Group ID\|Group ID(s)]] to be defined (#define MyGroupID) in the source file of the caller/callee of the routine to protect against the inclusion of unnecessary defined types.		<span id="Explicit_Mangling">'''Explicit mangling'''</span> is used to resolve these type of name mangling conflicts. Explicit mangling uses the explicit macro "'''srTEST_INTERCEPT('''<function_name>''')'''", which explicitly mangles the name of "f()" to "__im_f()". The explicit macro is defined in the Intercept Module name mangling header file (xxxIM.h). Explicit mangling requires [[Intercept Module#Group ID\|Group ID(s)]] to be defined (#define MyGroupID) in the source file of the caller/callee of the routine to protect against the inclusion of unnecessary defined types.

	The following examples demonstrate situations where explicit mangling can be used to resolve mangling conflicts:		The following examples demonstrate situations where explicit mangling can be used to resolve mangling conflicts:

Timd: /* ''Mangling Conflict Example 2: Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor'' */

2009-04-10T18:33:17Z

''Mangling Conflict Example 2: Two (or more) references of a routine, f(), exist in the same source file, but only one is a reference interceptor''

← Older revision		Revision as of 18:33, 10 April 2009
Line 46:		Line 46:
	<br>		<br>

	To enable Intercept Modules to be regenerated continuously and to allow the user the option to add and/or remove interceptors, an [[#Explicit_Mangling\|explicit macro]] is generated for each routine. If a routine is not selected as an interceptor, an explicit macro will be generated so that name mangling will not occur. Also, if use of the Intercept Module is turned off via the source file (e.g., #undef STRIDE_ENABLED or #define ~~STRIDE_EBALED=~~0), the macros will not perform name mangling. This allows users to leave explicit macros in their source code, even if the Intercept Module is not being used.		To enable Intercept Modules to be regenerated continuously and to allow the user the option to add and/or remove interceptors, an [[#Explicit_Mangling\|explicit macro]] is generated for each routine. If a routine is not selected as an interceptor, an explicit macro will be generated so that name mangling will not occur. Also, if use of the Intercept Module is turned off via the source file (e.g., <tt>#undef STRIDE_ENABLED</tt> or <tt>#define STRIDE_ENABLED 0</tt>), the macros will not perform name mangling. This allows users to leave explicit macros in their source code, even if the Intercept Module is not being used.

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