User-Level Native Thread Primitives (GThread) Library White Paper (G06.27+, H06.03+, J06.03+)

User-Level Native Thread Primitives (GThread Library) 02/15/2012
540065-004 Page 27 of 44
GTH_VALIDATE_GUARD_( GThread_CB cb, int32 mem_guard, int32 reg_guard )
Description:
Performs a validation of the pattern written during GTHREAD_INITIATE_ in the allocated stack
area. The validation is performed starting at the ‘end of the stack area’ allocated for the specified
length. The ‘end of the stack area’ is defined as the end of the allocated area based on the direction of
stack growth. On TNS/E platforms, the stack areas allocated for both the mem and reg stacks are
checked.
Input:
cb - The address of the thread control block for the thread being checked.
mem_guard – The amount of mem stack space, in bytes, reserved as the guard area.
reg_guard - The amount of reg stack space, in bytes, reserved as a guard area. On platforms other
than TNS/E native, this argument is ignored.
Return: int16
Returns nonzero if:
• The thread model is swapped
• The stack space wasn’t allocated
• mem_guard is greater than allocated mem stack space
• reg_guard is greater than allocated reg stack space
• A guard area has been overwritten or was not initialized with GTS_STATIC_FILL
Returns zero if the guard area has not been overwritten or if called for a protected stack.
Considerations:
For this function to work properly, the GTS_STATIC_FILL Swaptions define must have been
specified during GTHREAD_INITIATE_ for the specified thread. See Section 2.11 for more
information on this option.
The mem_guard and reg_guard values should each be less than or equal to the space the user
intended to remain as guard areas for the mem and reg stacks, respectively.
Specification of zero or a negative value for either mem_guard or reg_guard is invalid; the
consequences associated with using a negative value are undefined.
For TNS and TNS/R, the concept of a separate reg stack does not exist and the contents of
reg_guard are ignored for the aforementioned checks.
This function is subject to the same limitations described in Section 3.6.3.2 concerning using guard
areas as protection against overflows of static stacks. It is provided as a ‘built in’ for clients who use
guard areas for overflow protection. The following are some basic guidelines for usage:
• Larger guard areas increase probability of detection and of containment of corruption.
However, they take longer to check.
• Shorter guard areas take less time to check, and they can more readily be entirely overwritten.
Also, a short mem_guard can be ‘stepped over’ by large memory stack frames that are sparsely
written. (The reg stack is always written densely.)