Msg/FetchSelfModifyingCode - Revision history

Henry at 04:04, 17 March 2019

2019-03-17T04:04:44Z

@@ Line 24: / Line 24: @@
 	nop
 	nop						# This instruction gets changed to an add (opcode 0x18c00044)
 	nop
 </syntaxhighlight>

Henry: /* Examples */

2019-03-11T07:12:36Z

Examples

← Older revision		Revision as of 07:12, 11 March 2019
Line 27:		Line 27:
	</syntaxhighlight>		</syntaxhighlight>

	On the simulator, the highlighted instruction executes as an add (r3 gets incremented), ~~and~~ not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined ~~(you may execute the old or new instruction)~~ until you've flushed the instruction cache and flushed the instruction pipeline.		On the simulator, the highlighted instruction executes as an add (r3 gets incremented), not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined until you've flushed the instruction cache and flushed the instruction pipeline.

	=== Debugging ===		=== Debugging ===

Henry: /* ARMv7 */

2019-03-11T07:11:07Z

ARMv7

← Older revision		Revision as of 07:11, 11 March 2019
Line 5:		Line 5:
	=== Examples ===		=== Examples ===
	==== ARMv7 ====		==== ARMv7 ====
	<syntaxhighlight line lang="Asm" highlight="6">		<syntaxhighlight line lang="Asm" highlight="7">
	.global _start		.global _start
	_start:		_start:
	ldr r0, =0xe2822001 // An opcode		ldr r0, =0xe2822001 // An opcode
	str r0, [pc, #4] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.		str r0, [pc, #4] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.
	nop		nop
	nop		nop
	nop // This instruction gets changed to an add (opcode 0xe2822001)		nop // This instruction gets changed to an add (opcode 0xe2822001)
	nop		nop
	</syntaxhighlight>		</syntaxhighlight>

Henry: /* Nios II */

2019-03-11T07:10:47Z

Nios II

← Older revision		Revision as of 07:10, 11 March 2019
Line 23:		Line 23:
	stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.		stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.
	nop		nop
	nop # This instruction gets changed to an add (opcode 0x18c00044)		nop # This instruction gets changed to an add (opcode 0x18c00044)
	nop		nop
	</syntaxhighlight>		</syntaxhighlight>

Henry: /* Nios II */

2019-03-11T07:10:37Z

Nios II

← Older revision		Revision as of 07:10, 11 March 2019
Line 21:		Line 21:
	_start:		_start:
	movia r2, 0x18c00044 # An opcode		movia r2, 0x18c00044 # An opcode
	stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.		stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.
	nop		nop
	nop # This instruction gets changed to an add (opcode 0x18c00044)		nop # This instruction gets changed to an add (opcode 0x18c00044)
	nop		nop
	</syntaxhighlight>		</syntaxhighlight>

	On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.		On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.

	=== Debugging ===		=== Debugging ===

Henry: /* ARMv7 */

2019-03-11T07:10:06Z

ARMv7

← Older revision		Revision as of 07:10, 11 March 2019
Line 9:		Line 9:
	_start:		_start:
	ldr r0, =0xe2822001 // An opcode		ldr r0, =0xe2822001 // An opcode
	str r0, [pc, #0] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.		str r0, [pc, #4] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.
	nop		nop
			nop
	nop // This instruction gets changed to an add (opcode 0xe2822001)		nop // This instruction gets changed to an add (opcode 0xe2822001)
	nop		nop
	</syntaxhighlight>		</syntaxhighlight>

	==== Nios II ====		==== Nios II ====
	<syntaxhighlight line lang="Asm" highlight="6">		<syntaxhighlight line lang="Asm" highlight="6">

Henry at 07:08, 11 March 2019

2019-03-11T07:08:20Z

← Older revision		Revision as of 07:08, 11 March 2019
Line 31:		Line 31:

	* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.		* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.
	* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can ~~interrupt~~ the program whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.		* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can pause the program (like a breakpoint) whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.

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

Henry: /* Debugging */

2019-03-11T07:07:00Z

Debugging

← Older revision		Revision as of 07:07, 11 March 2019
Line 28:		Line 28:
	=== Debugging ===		=== Debugging ===

	Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. The ~~main~~ objective is to find which part of the program stored values into memory space used by your program's instructions.		Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. Also, the code currently shown in the disassembly window may not match the code that was originally loaded into memory. The objective is to find which part of the program stored values into the memory space used by your program's instructions.

	* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.		* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.

Henry at 07:04, 11 March 2019

2019-03-11T07:04:20Z

← Older revision		Revision as of 07:04, 11 March 2019
Line 32:		Line 32:
	* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.		* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.
	* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can interrupt the program whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.		* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can interrupt the program whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.

			=== Implementation ===
			The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.

			If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.

	{{DisableMsg\|Instruction fetch: Modified opcode}}		{{DisableMsg\|Instruction fetch: Modified opcode}}

Henry: Created page with "Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly..."

2019-03-11T06:55:37Z

Created page with "Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly..."

New page

Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.

There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.

=== Examples ===
==== ARMv7 ====
<syntaxhighlight line lang="Asm" highlight="6">
.global _start
_start:
ldr r0, =0xe2822001 // An opcode
str r0, [pc, #0] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.
nop
nop // This instruction gets changed to an add (opcode 0xe2822001)
nop
</syntaxhighlight>
==== Nios II ====
<syntaxhighlight line lang="Asm" highlight="6">
.global _start
_start:
movia r2, 0x18c00044 # An opcode
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.
nop
nop # This instruction gets changed to an add (opcode 0x18c00044)
nop
</syntaxhighlight>

On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.
=== Debugging ===

Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. The main objective is to find which part of the program stored values into memory space used by your program's instructions.

* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can interrupt the program whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.

{{DisableMsg|Instruction fetch: Modified opcode}}