Msg/StackDeallocatedParentFrame - Revision history

Henry at 04:14, 17 March 2019

2019-03-17T04:14:51Z

← Older revision		Revision as of 04:14, 17 March 2019
Line 10:		Line 10:
	_start:		_start:
	mov sp, #0x1000 // Initialize SP to something sane		mov sp, #0x1000 // Initialize SP to something sane
	bl Func		bl Func

	Func:		Func:
	add sp, #4 // ~~Deallocated~~ 4 bytes of the caller's stack frame		add sp, #4 // Deallocate 4 bytes of the caller's stack frame
	sub sp, #4 // Can't do this even if the operation is reverted		sub sp, #4 // Can't do this even if the operation is reverted
	bx lr		bx lr
	</syntaxhighlight>		</syntaxhighlight>
	==== Nios II ====		==== Nios II ====
Line 22:		Line 22:
	_start:		_start:
	movi sp, 0x1000 # Initialize SP to something sane		movi sp, 0x1000 # Initialize SP to something sane
	call Func		call Func

	Func:		Func:
	addi sp, sp, 4 # ~~Deallocated~~ 4 bytes of the caller's stack frame		addi sp, sp, 4 # Deallocate 4 bytes of the caller's stack frame
	subi sp, sp, 4 # Can't do this even if the operation is reverted		subi sp, sp, 4 # Can't do this even if the operation is reverted
	~~ret~~		ret
			</syntaxhighlight>
			==== MIPS ====
			<syntaxhighlight line lang="Asm" highlight="7">
			.global _start
			_start:
			li $sp, 0x1000 # Initialize SP to something sane
			jal Func

			Func:
			addiu $sp, $sp, 4 # Deallocate 4 bytes of the caller's stack frame
			addiu $sp, $sp, -4 # Can't do this even if the operation is reverted
			jr $ra
	</syntaxhighlight>		</syntaxhighlight>

Henry at 07:24, 10 March 2019

2019-03-10T07:24:28Z

← Older revision		Revision as of 07:24, 10 March 2019
Line 35:		Line 35:

	=== Debugging ===		=== Debugging ===
	* Normally, all stack pointer manipulations are matched: ~~Decrease~~ the stack pointer when entering a function, and ~~increasing~~ the stack pointer immediately before returning. ~~Check for~~ stack pointer ~~operations~~ (~~push~~ and ~~pop~~) ~~that~~ are ~~mismatched~~.		* Normally, all stack pointer manipulations are matched: decrease the stack pointer when entering a function, and increase the stack pointer immediately before returning.
			* Carefully trace through any operations that change the stack pointer. Make sure they're all matched (every decrement is matched by an increment of the same amount). Ensure that the function prologue and epilogue only execute once (not accidentally part of a loop).
			* The two places where stack pointer manipulations often occur are at the function prologue and epilogue, and allocating and deallocating arguments passed on the stack when calling a function. These operations are all matched. If your function uses the stack pointer for other purposes, this is an easy source of bugs.

	=== Implementation ===		=== Implementation ===

Henry: /* Implementation */

2019-03-10T06:47:57Z

Implementation

← Older revision		Revision as of 06:47, 10 March 2019
Line 38:		Line 38:

	=== Implementation ===		=== Implementation ===
	This warning is generated at the instruction that modifies the stack pointer.		The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and compares the current stack pointer to the stack pointer at the beginning of the function. This warning is generated at the instruction that modifies the stack pointer.

	{{DisableMsg\|SP moved beyond current stack frame}}		{{DisableMsg\|SP moved beyond current stack frame}}

Henry at 06:47, 10 March 2019

2019-03-10T06:47:02Z

← Older revision		Revision as of 06:47, 10 March 2019
Line 6:		Line 6:
	==== ARMv7 ====		==== ARMv7 ====

	<syntaxhighlight line lang="Asm">		<syntaxhighlight line lang="Asm" highlight="7">
	.global _start		.global _start
	_start:		_start:
Line 18:		Line 18:
	</syntaxhighlight>		</syntaxhighlight>
	==== Nios II ====		==== Nios II ====
	<syntaxhighlight line lang="Asm">		<syntaxhighlight line lang="Asm" highlight="7">
	.global _start		.global _start
	_start:		_start:
Line 36:		Line 36:
	=== Debugging ===		=== Debugging ===
	* Normally, all stack pointer manipulations are matched: Decrease the stack pointer when entering a function, and increasing the stack pointer immediately before returning. Check for stack pointer operations (push and pop) that are mismatched.		* Normally, all stack pointer manipulations are matched: Decrease the stack pointer when entering a function, and increasing the stack pointer immediately before returning. Check for stack pointer operations (push and pop) that are mismatched.

			=== Implementation ===
			This warning is generated at the instruction that modifies the stack pointer.

	{{DisableMsg\|SP moved beyond current stack frame}}		{{DisableMsg\|SP moved beyond current stack frame}}

Henry: Created page with "A stack frame is a region of memory used by an executing function. When calling a function, the child function's stack frame is at a lower address than the caller's stack fram..."

2019-03-10T06:44:46Z

Created page with "A stack frame is a region of memory used by an executing function. When calling a function, the child function's stack frame is at a lower address than the caller's stack fram..."

New page

A stack frame is a region of memory used by an executing function. When calling a function, the child function's stack frame is at a lower address than the caller's stack frame. New stack space is allocated by decrementing the stack pointer, and stack space is deallocated by incrementing the stack pointer. However, a function should not deallocate the parent function's stack frame. In other words, the stack pointer should never be greater than the value at the beginning of the function. This warning tells you that the stack pointer has increased past the value it had at the beginning of the current function.

This is a more stringent requirement than simply requiring the stack pointer to be restored to its original value at the end of the function. Because an interrupt can occur at any moment, if the stack pointer increases beyond the current stack frame (deallocating the parent's stack frame) even momentarily, the parent function may lose some of its stack values because an interrupt handler may have executed and used the "free" stack space below the stack pointer.

=== Example ===
==== ARMv7 ====

<syntaxhighlight line lang="Asm">
.global _start
_start:
mov sp, #0x1000 // Initialize SP to something sane
bl Func

Func:
add sp, #4 // Deallocated 4 bytes of the caller's stack frame
sub sp, #4 // Can't do this even if the operation is reverted
bx lr
</syntaxhighlight>
==== Nios II ====
<syntaxhighlight line lang="Asm">
.global _start
_start:
movi sp, 0x1000 # Initialize SP to something sane
call Func

Func:
addi sp, sp, 4 # Deallocated 4 bytes of the caller's stack frame
subi sp, sp, 4 # Can't do this even if the operation is reverted
ret
</syntaxhighlight>

In the above examples, the stack pointer is initialized to 0x1000. The child function Func can allocate and deallocate stack space below the stack pointer (currently 0x1000). It is not allowed to deallocate the parent's stack frame. The child function here attempts to move the stack pointer to 0x1004. This results in the warning: '''Stack pointer moved beyond current stack frame. sp at beginning of current function was 00001000'''

The message also reminds you that the stack pointer was 0x1000 at the beginning of the function, and that the stack pointer has increased beyond this point (to 0x1004).

=== Debugging ===
* Normally, all stack pointer manipulations are matched: Decrease the stack pointer when entering a function, and increasing the stack pointer immediately before returning. Check for stack pointer operations (push and pop) that are mismatched.

{{DisableMsg|SP moved beyond current stack frame}}