IOS/Kernel: Difference between revisions
Hallowizer (talk | contribs) →Threads: IOSP is started by the reset vector, not created retroactively for the reset vector |
Hallowizer (talk | contribs) →Threads: more info from thread joins |
||
| Line 27: | Line 27: | ||
u32 state; // 0x50 - 0 for a destroyed/uncreated thread, 1 for an active thread, 2 for the current thread, 3 for a thread that has not been started, 4 for a blocked thread | u32 state; // 0x50 - 0 for a destroyed/uncreated thread, 1 for an active thread, 2 for the current thread, 3 for a thread that has not been started, 4 for a blocked thread | ||
u32 processId; // 0x54 | u32 processId; // 0x54 | ||
u32 | bool detached; // 0x58 | ||
u32 result; // 0x5C | |||
u32 | IOS_ThreadQueue joinQueue; // 0x60 | ||
IOS_ThreadQueue *queue; // 0x64 | |||
u32 unknown2[0x42]; // 0x68 | |||
} | } | ||
</pre> | </pre> | ||
Note that <code>IOS_ThreadQueue</code> is just a pointer to an <code>IOS_Thread</code>. | |||
Unlike in [[Revolution OS]], where the initial thread is created over the current code with <code>__OSThreadInit</code>, the first IOS thread ([[IOSP]]) is created by the reset vector, launching new code with the standard <code>IOS_CreateThread</code> function. | Unlike in [[Revolution OS]], where the initial thread is created over the current code with <code>__OSThreadInit</code>, the first IOS thread ([[IOSP]]) is created by the reset vector, launching new code with the standard <code>IOS_CreateThread</code> function. | ||
Revision as of 02:07, 11 April 2022
The IOS kernel is responsible for dispatching interrupts to processes, handling syscalls, and running the IOSP threads. It is independent of the Wii's specific architecture, as Wii-specific functions such as high-level title launching are provided by ES.
Threads
IOS uses this struct to keep track of a thread. The first 0x40 bytes may belong to an OSContext-like struct.
struct IOS_Thread {
u32 cpsr; // 0x0
u32 r0; // 0x4
u32 r1; // 0x8
u32 r2; // 0xC
u32 r3; // 0x10
u32 r4; // 0x14
u32 r5; // 0x18
u32 r6; // 0x1C
u32 r7; // 0x20
u32 r8; // 0x24
u32 r9; // 0x28
u32 r10; // 0x2C
u32 r11; // 0x30
u32 r12; // 0x34
void *sp; // 0x38
void *lr; // 0x3C
void *resumeAddr; // 0x40
struct IOS_Thread *next; // 0x44
u32 unknown; // 0x48
s32 priority; // 0x4C
u32 state; // 0x50 - 0 for a destroyed/uncreated thread, 1 for an active thread, 2 for the current thread, 3 for a thread that has not been started, 4 for a blocked thread
u32 processId; // 0x54
bool detached; // 0x58
u32 result; // 0x5C
IOS_ThreadQueue joinQueue; // 0x60
IOS_ThreadQueue *queue; // 0x64
u32 unknown2[0x42]; // 0x68
}
Note that IOS_ThreadQueue is just a pointer to an IOS_Thread.
Unlike in Revolution OS, where the initial thread is created over the current code with __OSThreadInit, the first IOS thread (IOSP) is created by the reset vector, launching new code with the standard IOS_CreateThread function.
Memory allocation
Memory allocation is similar to in the IPC library, although the IOS kernel supports 16 heaps instead of 8.
struct HeapBlockHeader {
u16 magic; // 0xbabe
u16 status; // 0 = free, 1 = allocated, 2 = aligned alias for header
u32 size;
struct HeapBlockHeader *prev; // depends on status; status 0 has the previous free block, status 1 has NULL, status 2 has the main block
struct HeapBlockHeader *next; // NULL for anything besides status 0
}
struct Heap {
void *base;
u32 processId;
u32 size;
struct HeapBlockHeader *firstBlock;
}
When writing an aligned copy of a block, IOS does not check if it overlaps the existing copy; this could potentially be exploited.