KThreadContext - Revision history

TuxSH at 15:56, 24 December 2016

2016-12-24T14:56:30Z

← Older revision		Revision as of 17:56, 24 December 2016
Line 39:		Line 39:
	0: Bit0: reschedule. Bit1: switch context. If non zero, and depending on <code>currentThread->shallTerminate</code>, send thread exit debug events after handling valid/authorized SVCs (except 0xFF). Cleared to zero after handling. Bit2: lock debug features		0: Bit0: reschedule. Bit1: switch context. If non zero, and depending on <code>currentThread->shallTerminate</code>, send thread exit debug events after handling valid/authorized SVCs (except 0xFF). Cleared to zero after handling. Bit2: lock debug features

	1: "Allow debug" flag from the process's exheader. If set, <code>{r0-r7, r12, lr}</code> will be pushed (they'll always be when handling invalid/unauthorized SVCs/SVC 0xFF). Needed for svcGetThreadContext and svcSetThreadContext to work properly in contexts other than exception handling.		1: "Allow debug" flag from the process's exheader. If set, <code>{r0-r7, r12, lr_svc}</code> will be pushed (they'll always be when handling invalid/unauthorized SVCs/SVC 0xFF). Needed for svcGetThreadContext and svcSetThreadContext to work properly in contexts other than exception handling (incl. hardware breakpoints). If lr_svc is set to one in this frame, the registers are reloaded from it (used with svcBreak, svc 0xff, etc).

	2: ?		2: ?

	3: ID of the SVC being handled (reset to 0 when done).		3: ID of the SVC being handled (reset to 0 when done).
	\|-
	~~\| 0xF4C (page_end - 0xB4)~~
	~~\| u32~~
	~~\| If non-zero, reloads <code>{r0-r7, r12, lr}</code> (otherwise skipped) from the stack after handling a SVC.~~
	\|-		\|-
	\| 0xF50 (page_end - 0xB0)		\| 0xF50 (page_end - 0xB0)

TuxSH at 13:56, 24 December 2016

2016-12-24T12:56:59Z

← Older revision		Revision as of 15:56, 24 December 2016
Line 37:		Line 37:
	\| u8[4]		\| u8[4]
	\| Debug info (read by the SVC handler):		\| Debug info (read by the SVC handler):
	0: Bit0: reschedule. Bit1: switch context. If non zero, and depending on <code>currentThread->shallTerminate</code>, send thread exit debug events after handling valid/authorized SVCs (except 0xFF). Cleared to zero after handling.		0: Bit0: reschedule. Bit1: switch context. If non zero, and depending on <code>currentThread->shallTerminate</code>, send thread exit debug events after handling valid/authorized SVCs (except 0xFF). Cleared to zero after handling. Bit2: lock debug features

	1: "Allow debug" flag from the process's exheader. If set, <code>{r0-r7, r12, lr}</code> will be pushed (they'll always be when handling invalid/unauthorized SVCs/SVC 0xFF).		1: "Allow debug" flag from the process's exheader. If set, <code>{r0-r7, r12, lr}</code> will be pushed (they'll always be when handling invalid/unauthorized SVCs/SVC 0xFF). Needed for svcGetThreadContext and svcSetThreadContext to work properly in contexts other than exception handling.

	2: ?		2: ?

TuxSH at 19:32, 3 December 2016

2016-12-03T18:32:11Z

← Older revision		Revision as of 21:32, 3 December 2016
Line 37:		Line 37:
	\| u8[4]		\| u8[4]
	\| Debug info (read by the SVC handler):		\| Debug info (read by the SVC handler):
	0: Bit0: reschedule. Bit1: switch context. If non zero, and depending on <code>((u8 )currentThread ~~+ 0x36)~~</code>, send thread exit debug events after handling valid/authorized SVCs (except 0xFF). Cleared to zero after handling.		0: Bit0: reschedule. Bit1: switch context. If non zero, and depending on <code>currentThread->shallTerminate</code>, send thread exit debug events after handling valid/authorized SVCs (except 0xFF). Cleared to zero after handling.

	1: "Allow debug" flag from the process's exheader. If set, <code>{r0-r7, r12, lr}</code> will be pushed (they'll always be when handling invalid/unauthorized SVCs/SVC 0xFF).		1: "Allow debug" flag from the process's exheader. If set, <code>{r0-r7, r12, lr}</code> will be pushed (they'll always be when handling invalid/unauthorized SVCs/SVC 0xFF).

TuxSH at 17:45, 2 December 2016

2016-12-02T16:45:26Z

@@ Line 33: / Line 33: @@
 | u32[4]
 | SVC access control data copied from KThread's owner process
 |-
 | 0xF50 (page_end - 0xB0)

Bond697 at 05:23, 31 August 2016

2016-08-31T03:23:33Z

← Older revision		Revision as of 07:23, 31 August 2016
Line 37:		Line 37:
	\| u32[10]		\| u32[10]
	\| SVC mode registers, r4-r11, r13, r14		\| SVC mode registers, r4-r11, r13, r14
			\|-
			\| 0xF78
			\| f64[16]
			\| VFP registers aliased as 16 double precision, 64-bit registers
	\|-		\|-
	\| 0xFF8		\| 0xFF8
	\| u32		\| u32
	\| FPEXC, floating point exception register for thread- stored and loaded on context switches		\| FPEXC, floating point exception register for thread- stored and loaded on context switches
			\|-
			\| 0xFFC
			\| u32
			\| FPSCR, floating point status and control register
	\|}		\|}

Bond697 at 03:22, 30 August 2016

2016-08-30T01:22:59Z

← Older revision		Revision as of 05:22, 30 August 2016
Line 2:		Line 2:

	Size : 0x1000 bytes (1 page)		Size : 0x1000 bytes (1 page)

			Each [[KThread\|thread]] is allocated a 0x1000-byte page in this region for the [[KThreadContext\|thread context]]. Each thread has its context address stored as 2 members:


			{\| class="wikitable" border="1"
			\|-
			! Offset
			! Type
			! Description
			\|-
			\| 0x88
			\| u32*
			\| Ptr to svc mode register storage for KThread inside the thread context.
			\|-
			\| 0x8C
			\| u32*
			\| End-address of the page for this thread context allocated in the [[Memory_layout\|0xFF4XX000]] region.
			\|}

			KThread offset 0x88 points to offset 0xF50 in the thread context and 0x8C points to the end of the thread context page. The kernel refers to the thread context page by subtracting from the end instead of adding from the beginning.

Bond697 at 16:24, 29 August 2016

2016-08-29T14:24:42Z

← Older revision		Revision as of 18:24, 29 August 2016
Line 10:		Line 10:
	! Description		! Description
	\|-		\|-
	\| 0xF38		\| 0xF38 (page_end - 0xC8)
	\| u32[4]		\| u32[4]
	\| SVC access control data copied from KThread's owner process		\| SVC access control data copied from KThread's owner process
	\|-		\|-
	\| 0xF50		\| 0xF50 (page_end - 0xB0)
	\| u32[10]		\| u32[10]
	\| SVC mode registers, r4-r11, r13, r14		\| SVC mode registers, r4-r11, r13, r14

Bond697: Undo revision 18002 by Neobrain (talk)

2016-08-29T12:45:21Z

Undo revision 18002 by Neobrain (talk)

← Older revision		Revision as of 16:45, 29 August 2016
Line 1:		Line 1:
			[[Category:Kernel objects]]

	Size : 0x1000 bytes (1 page)		Size : 0x1000 bytes (1 page)


	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
Line 29:		Line 32:
	* Check if that core's KScheduler object indicates that it needs switching again and exit if it does not		* Check if that core's KScheduler object indicates that it needs switching again and exit if it does not
	* Otherwise, run the thread scheduler again and repeat all the steps to switch contexts again		* Otherwise, run the thread scheduler again and repeat all the steps to switch contexts again

	~~[[Category:Kernel objects]]~~

Neobrain at 07:25, 29 August 2016

2016-08-29T05:25:25Z

← Older revision		Revision as of 09:25, 29 August 2016
Line 1:		Line 1:
	~~[[Category:Kernel objects]]~~

	Size : 0x1000 bytes (1 page)		Size : 0x1000 bytes (1 page)


	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
Line 32:		Line 29:
	* Check if that core's KScheduler object indicates that it needs switching again and exit if it does not		* Check if that core's KScheduler object indicates that it needs switching again and exit if it does not
	* Otherwise, run the thread scheduler again and repeat all the steps to switch contexts again		* Otherwise, run the thread scheduler again and repeat all the steps to switch contexts again

			[[Category:Kernel objects]]

Bond697 at 23:11, 28 August 2016

2016-08-28T21:11:09Z

← Older revision		Revision as of 01:11, 29 August 2016
Line 9:		Line 9:
	! Type		! Type
	! Description		! Description
			\|-
			\| 0xF38
			\| u32[4]
			\| SVC access control data copied from KThread's owner process
	\|-		\|-
	\| 0xF50		\| 0xF50
Line 25:		Line 29:
	* Load r4-r11, SP, LR		* Load r4-r11, SP, LR
	* Branch back to r1, preserving the LR which was just reloaded, back to the main scheduling function, but in the context of the newly switched-to thread		* Branch back to r1, preserving the LR which was just reloaded, back to the main scheduling function, but in the context of the newly switched-to thread
			* Disable Interrupts
			* Check if that core's KScheduler object indicates that it needs switching again and exit if it does not
			* Otherwise, run the thread scheduler again and repeat all the steps to switch contexts again