151
edits
Changes
Jump to navigation
Jump to search
mLine 25:
Line 25: − + Line 207:
Line 207: − + Line 478:
Line 478: − + − | (Out) W0 || [[#Result]] || Ret Line 486:
Line 485: − + + + + + + + + + + + + + + + Line 646:
Line 659: − + + + Line 652:
Line 667: − + + + + + + + − + + + + + − + Line 664:
Line 689: − + + + − + Line 1,656:
Line 1,683: − + Line 1,680:
Line 1,707: − + Line 1,690:
Line 1,717: + + Line 2,009:
Line 2,038: − + − + + Line 2,053:
Line 2,083: − + Line 2,073:
Line 2,103: − + − + Line 2,085:
Line 2,115: − + − + + + + + + + + + + + + + + + + + + + + + + + + Line 2,096:
Line 2,149: − + − afsr0, afsr1, esr, pc (stored using the regs' own size) + + + + + + + + + + + + + + + + + + + + + + + + + Line 2,130:
Line 2,207: + + + +
Fix offset in CreateProcessInfo
| 0xA || [[#svcExitThread]] || None ||
| 0xA || [[#svcExitThread]] || None ||
|-
|-
| 0xB || [[#svcSleepThread]] || X0=nano || W0=result
| 0xB || [[#svcSleepThread]] || X0=nano ||
|-
|-
| 0xC || [[#svcGetThreadPriority]] || W1=thread_handle || W0=result, W1=prio
| 0xC || [[#svcGetThreadPriority]] || W1=thread_handle || W0=result, W1=prio
| 0x6F || [5.0.0+] [[#svcGetSystemInfo]] || X1=info_id, X2=handle, X3=info_sub_id || W0=result, X1=out
| 0x6F || [5.0.0+] [[#svcGetSystemInfo]] || X1=info_id, X2=handle, X3=info_sub_id || W0=result, X1=out
|-
|-
| 0x70 || svcCreatePort || W2=max_sessions, W3=unk_bool, X4=name_ptr || W0=result, W1=clientport_handle, W2=serverport_handle
| 0x70 || svcCreatePort || W2=max_sessions, W3=is_light, X4=name_ptr || W0=result, W1=clientport_handle, W2=serverport_handle
|-
|-
| 0x71 || svcManageNamedPort || X1=name_ptr, W2=max_sessions || W0=result, W1=serverport_handle
| 0x71 || svcManageNamedPort || X1=name_ptr, W2=max_sessions || W0=result, W1=serverport_handle
! Argument || Type || Name
! Argument || Type || Name
|-
|-
| (In) X0 || u64 || Nano
| (In) X0 || s64 || Nanoseconds
|-
|-
|}
|}
</div>
</div>
'''Description:''' Sleep for a specified amount of time, or yield thread.
'''Description:''' Sleep for a specified amount of time, or yield thread.
Setting nano=0 means "yield thread".
Setting nanoseconds to 0, -1, or -2 indicates a yielding type.
<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Value || Type
|-
| 0 || Yielding without core migration
|-
| -1 || Yielding with core migration
|-
| -2 || Yielding to any other thread
|-
|}
</div>
== svcGetThreadPriority ==
== svcGetThreadPriority ==
</div>
</div>
Works with num_handles <= 0x40, error on num_handles == 0.
Works with num_handles <= 0x40.
When zero handles are passed, this will wait forever until either timeout or cancellation occurs.
Does not accept 0xFFFF8001 or 0xFFFF8000 as handles.
Does not accept 0xFFFF8001 or 0xFFFF8000 as handles.
=== Object types ===
=== Object types ===
'''Port:''' signals when there is an incoming connection waiting to be [[#svcAcceptSession|accepted]].
'''KDebug:''' signals when there is a new [[#DebugEventInfo|DebugEvent]] (retrievable via [[#svcGetDebugEvent]]).
'''KClientPort:''' signals when the number of sessions is less than the maximum allowed.
'''KProcess:''' signals when the process undergoes a state change (retrievable via [[#svcGetProcessInfo]]).
'''KReadableEvent:''' signals when the event's corresponding KWritableEvent has been signaled via svcSignalEvent.
'''Session (server-side):''' signals when there is an incoming message waiting to be [[#svcReplyAndReceive|received]] or the pipe is closed.
'''KServerPort:''' signals when there is an incoming connection waiting to be [[#svcAcceptSession|accepted]].
'''KServerSession:''' signals when there is an incoming message waiting to be [[#svcReplyAndReceive|received]] or the pipe is closed.
'''KThread:''' signals when the thread has exited.
=== Result codes ===
=== Result codes ===
'''0x0:''' Success. One of the objects was signalled before the timeout expired. Handle index is updated to indicate which object signalled.
'''0x0:''' Success. One of the objects was signaled before the timeout expired, or one of the objects is a Session with a closed remote. Handle index is updated to indicate which object signaled.
'''0x7601:''' Thread termination requested. Handle index is not updated.
'''0x7601:''' Thread termination requested. Handle index is not updated.
'''0xe401:''' Invalid handle. Returned when one of the handles passed is invalid. Handle index is not updated.
'''0xe401:''' Invalid handle. Returned when one of the handles passed is invalid. Handle index is not updated.
'''0xea01:''' Timeout. Returned when no objects have been signalled within the timeout. Handle index is not updated.
'''0xe601:''' Invalid address. Returned when the handles pointer is not a readable address. Handle index is not updated.
'''0xea01:''' Timeout. Returned when no objects have been signaled within the timeout. Handle index is not updated.
'''0xec01:''' Interrupted. Returned when another thread uses [[#svcCancelSynchronization]] to cancel this thread. Handle index is not updated.
'''0xec01:''' Interrupted. Returned when another thread uses [[#svcCancelSynchronization]] to cancel this thread. Handle index is not updated.
'''0xf601:''' Session closed. Returned when one of the handles represents a session that has been closed. Handle index is updated.
'''0xee01:''' Too many handles. Returned when the number of handles passed is > 0x40.
== svcCancelSynchronization ==
== svcCancelSynchronization ==
| 0 || 12 || || ProcessName (doesn't have to be null-terminated)
| 0 || 12 || || ProcessName (doesn't have to be null-terminated)
|-
|-
| 0 || 4 || || ProcessCategory (0: regular title, 1: kernel built-in)
| 0x0C || 4 || || ProcessCategory (0: regular title, 1: kernel built-in)
|-
|-
| 0x10 || 8 || || TitleId
| 0x10 || 8 || || TitleId
| || || Bit10-7 || [5.0.0+] PoolPartition (0=Application, 1=Applet, 2=Sysmodule, 3=Nvservices)
| || || Bit10-7 || [5.0.0+] PoolPartition (0=Application, 1=Applet, 2=Sysmodule, 3=Nvservices)
|-
|-
| 0x28 || 4 || || ResourceLimitHandle
| 0x28 || 4 || || ResourceLimitHandle or zero
|-
|-
| 0x2C || 4 || || [3.0.0+] PersonalMmHeapNumPages
| 0x2C || 4 || || [3.0.0+] PersonalMmHeapNumPages
On [5.0.0] PoolPartition is specified in CreateProcessArgs. There are now 4 pool partitions.
On [5.0.0] PoolPartition is specified in CreateProcessArgs. There are now 4 pool partitions.
On [6.0.0] (maybe lower?) a zero ResourceLimitHandle defaults to sysmodule limits and 0x12300000 bytes of memory.
=== AddressSpaceType ===
=== AddressSpaceType ===
|}
|}
* Undefined instructions, software breakpoints, some other traps.
<nowiki>*</nowiki> Undefined instructions, software breakpoints, some other traps.
** Data aborts, FP traps, and everything else that doesn't belong to any of the above.
<nowiki>**</nowiki> Data aborts, FP traps, and everything else that doesn't belong to any of the above.
Trap specifics:
Trap specifics:
KDebug dispatching is used when at least one of the following conditions are met:
KDebug dispatching is used when at least one of the following conditions are met:
* SMC ConfigItem KernelMemConfig bit 1 is NOT set (it isn't on retail), unless: this is a software or hardware breakpoint, or a watchpoint, or [4.0.0+?] the process is attached and this is a Google PNaCl trap instruction (see LLVM source)
* SMC ConfigItem KernelMemConfig bit 1 is NOT set (it isn't on retail), unless: this is a software or hardware breakpoint, or a watchpoint, or [4.0.0+?] the process is attached and this is a Google PNaCl trap instruction (see LLVM source)
* PC doesn't point to a valid address in mapped-readable CodeStatic memory (i.e. this is the case for NRO and JIT memory) or this one of the following exceptions (it particular, that doesn't include FP exceptions occuring in CodeStatic memory):
* FAR doesn't point to a valid address in mapped-readable CodeStatic memory (i.e. this is the case for NRO and JIT memory) or this is one of the following exceptions (it particular, that doesn't include FP exceptions occurring in CodeStatic memory):
** Uncategorized
** Uncategorized
** IllegalState
** IllegalState
If the process is attached, the exception is reported to the KDebug. If the thread was continued using flag IgnoreExceptions, it returns from the exception as if nothing happened.
If the process is attached, the exception is reported to the KDebug. If the thread was continued using flag IgnoreExceptions, it returns from the exception as if nothing happened.
If the latter is not the case, or if the process isn't attached, process to [2.0.0+] crash reporting (or in [1.0.0] just terminate the process):
If the latter is not the case, or if the process isn't attached, proceed to [2.0.0+] crash reporting (or in [1.0.0] just terminate the process):
if EnableDebug is set, and depending on the process state (more than one crash per process isn't permitted) it may signal itself with ProcessState_Crashed so that PM asks NS to start creport so that creports attaches to it and reports the crashes. Otherwise, just terminate.
if EnableDebug is set, and depending on the process state (more than one crash per process isn't permitted) it may signal itself with ProcessState_Crashed so that PM asks NS to start creport so that creport attaches to it and reports the crashes. Otherwise, just terminate.
Userland reporting path and svcReturnFromException:
Userland reporting path and svcReturnFromException:
| 0x0 || 0x148 || Exception stack
| 0x0 || 0x148 || Exception stack
|-
|-
| 0x148 || 0x78 || Frame: x0..x30, sp, elr_el1=unadjusted PC, pstate & 0xFF0FFE20,
| 0x148 || 0x78 || ExceptionFrameA64
afsr0, afsr1, esr, pc (stored using the regs' own size)
|}
ExceptionFrameA64:
{| class=wikitable
! Offset || Length || Description
|-
| 0x0 || 0x48 (8*9) || GPRs 0..8.
|-
| 0x48 || 0x8 || lr
|-
| 0x50 || 0x8 || sp
|-
| 0x58 || 0x8 || pc (elr_el1)
|-
| 0x60 || 0x4 || pstate & 0xFF0FFE20
|-
| 0x64 || 0x4 || afsr0
|-
| 0x68 || 0x4 || afsr1
|-
| 0x6C || 0x4 || esr
|-
| 0x70 || 0x8 || far
|}
|}
| 0x0 || 0x178 || Exception stack
| 0x0 || 0x178 || Exception stack
|-
|-
| 0x148 || 0x30 || Frame: r0..r14, elr_el1=unadjusted PC, tpidr_el0 = 1, cpsr & 0xFF0FFE20,
| 0x148 || 0x44 || ExceptionFrameA32
|}
|}
ExceptionFrameA32:
{| class=wikitable
! Offset || Length || Description
|-
| 0x0 || 0x20 (8*4) || GPRs 0..7.
|-
| 0x20 || 0x4 || sp
|-
| 0x24 || 0x4 || lr
|-
| 0x28 || 0x4 || pc (elr_el1)
|-
| 0x2C || 0x4 || tpidr_el0 = 1
|-
| 0x30 || 0x4 || cpsr & 0xFF0FFE20
|-
| 0x34 || 0x4 || afsr0
|-
| 0x38 || 0x4 || afsr1
|-
| 0x3C || 0x4 || esr
|-
| 0x40 || 0x4 || far
|}
In that case, after storing the regs in the TLS, the exception handler returns to the application's crt0 (entrypoint), with X0=<error description code> (see below) and X1=SP=frame=<stack top> (see above)
In that case, after storing the regs in the TLS, the exception handler returns to the application's crt0 (entrypoint), with X0=<error description code> (see below) and X1=SP=frame=<stack top> (see above)
* if the provided error code is 0, gracefully pivots and returns from exception
* if the provided error code is 0, gracefully pivots and returns from exception
* if it is not, replays the exception and pass it to the KDebug (see above). One can pass 0x10001 to prevent process termination. If the process is attached, this also prevents crash-collection/termination (different from the exception handler behavior)
* if it is not, replays the exception and pass it to the KDebug (see above). One can pass 0x10001 to prevent process termination. If the process is attached, this also prevents crash-collection/termination (different from the exception handler behavior)
If an exception occurs from the above user handler, the entire exception handling process will repeat with the new exception.
Note that if a thread that wasn't faulting calls svcReturnFromException, it signals an "invalid syscall" exception
Note that if a thread that wasn't faulting calls svcReturnFromException, it signals an "invalid syscall" exception
Note that [[SMC|IsDebugMode]] is not used during exception-handling, except for enabling printing a message to UART-A. This UART code causes a system-hang on retail (likely due to a loop that doesn't exit). This printing doesn't seem to run when the process is attached for debugging?